ssh「権限がオープンしすぎています」エラー


2054

Macで問題が発生し、ディスクにファイルを保存できなくなりました。OSX lionを再起動し、ファイルとACLのアクセス許可をリセットする必要がありました。

しかし、リポジトリをコミットしたいとき、sshから次のエラーが表示されます。

Permissions 0777 for '/Users/username/.ssh/id_rsa' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.

id_rsaファイルにどのアクセス許可レベルを付与する必要がありますか?


20
質問をしていただきありがとうございます。このエラーメッセージを書いた人は、いくつかの有効な構成(以下に示す600や400など)を提案する方が良いでしょう。役立つ十分に完全なエラーメッセージを作成していないプログラマーは、何年もの間私たち全員を苦しめてきました!
George Pligoropoulos

FWIW、これが関連するStrictModes上で有効にされてsshdから、サーバーのmanページ:「sshd(8)のかどうかをStrictModesを指定し、ログインを受け入れる前に、ファイルのモードとユーザのファイルの所有権およびホームディレクトリを確認する必要があります。」-これを無効にすることもできますが、お勧めしません。
masseyb

回答:


3473

キーはあなただけが読めるようにする必要があります:

chmod 400 ~/.ssh/id_rsa

キーをあなたが読み書き可能にする必要がある場合:

chmod 600 ~/.ssh/id_rsa

600も問題ないように見えます(実際には、ファイルのアクセス許可を変更して後で編集する必要がないため、ほとんどの場合により優れています)。

マンページの関連部分(man ssh

 ~/.ssh/id_rsa
         Contains the private key for authentication.  These files contain sensitive 
         data and should be readable by the user but not
         accessible by others (read/write/execute).  ssh will simply ignore a private 
         key file if it is              
         accessible by others.  It is possible to specify a
         passphrase when generating the key which will be used to encrypt the sensitive 
         part of this file using 3DES.

 ~/.ssh/identity.pub
 ~/.ssh/id_dsa.pub
 ~/.ssh/id_ecdsa.pub
 ~/.ssh/id_rsa.pub
         Contains the public key for authentication.  These files are not sensitive and 
         can (but need not) be readable by anyone.

299
400は低すぎて、自分のユーザーが書き込みできないようになっています。600は、所有者が読み取りだけでなく読み取り/書き込みを許可するため、実際に推奨されます。
jfreak53

8
今日、400が適切な場合があることを発見しました。no-ptyなどの機能が設定されたauthorized_keysファイルがあるとします。ファイルが書き込み可能である場合、ユーザーは実際にauthorized_keysファイルを上書きし、インタラクティブなシェルアクセスを取得できます!覚えておくべきことですが、ほとんどの人にとって一般的なケースではありません。
quickshiftin 2013年

17
AWSは実際にウェブサイトでパーミッション400を推奨しています。それは私がOS Xでやったことであり、うまくいきました。
ジョージミロナス

5
これは間違いなく機能し、より安全です。唯一の欠点は、編集するには600に変更する必要があることです。id_rsaとid_rsa.pubの場合、これらのファイルを編集することはめったにないので、問題であることは疑わしいですが、authorized_keysの場合、煩わしい場合があります。トレードオフを理解し、各システムを適切に構成するのが最善です。
2016年

3
それはあなたがそれらを編集している頻度にも依存すると思います。多くの人が設定して忘れてしまうので、400は他の人やあなた自身の行動からより安全になります。必要に応じて600に変更します。それがワークフローの一部であり、sshに精通している場合は、アクセス許可を変更し続けることの妨げになる可能性があります。
vol7ron、2016年

99

Windows 8.1でCygwinを使用して、実行する必要があるコマンドがあります。

chgrpユーザー〜/ .ssh / id_rsa

次に、ここに投稿されたソリューションを適用できます。400または600で問題ありません。

chmod 600〜/ .ssh / id_rsa

参照:http : //vineetgupta.com/blog/cygwin-permissions-bug-on-windows-8


8
ロケール依存。「ユーザー」がそのようなグループにエラーを報告しなかったため、「chgrpUżytkownicy〜/ .ssh / id_rsa」を実行する必要がありました。
Marcos

私もこれをしなければなりませんでした。私のcygwinディレクトリはデフォルトの場所(C:\cygwin64)にあったため、おそらくアクセス許可を継承しました。私が所有している他のラップトップではこれが起こらなかったのは奇妙です。
Zach Thacker 2014年

3
@Marcosロケールに関係なく機能する回答を追加しました:stackoverflow.com/a/28647713/67013
thehouse

4
Windows10。2番目のコマンドのみを使用しました。魅力のように働いた。
StalkAlex

代替言語でのインストールの場合、「ユーザー」グループには代替の識別子があることに注意してください。
John Rumpel

43

Windows 8.1で機能するロケールに依存しないソリューションは次のとおりです。

chgrp 545 ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_rsa

GID 545は、ロケールがユーザーに対して別の単語を使用している場合でも、常に「ユーザー」グループを参照する特別なIDです。



24

AFAIKの値は次のとおりです。

キーファイルが配置されている隠しディレクトリ「.ssh」の場合は700

キーファイル「id_rsa」の場合は600


19

Windows 10でエラーが発生したので、次のように権限を設定すると機能します。

Windows 10のid_rsaの権限

詳細には、「システム」と「管理者」のみになるまで、他のユーザー/グループを削除します。次に、読み取り権限のみでWindowsログインを追加します。

id_rsaファイルがc:\users\<username>フォルダーの下にあることに注意してください。


Win-10でも同じ問題があります。説明に基づいて、実際に何を許可および拒否したかは明確ではありません-オプション+システムおよび管理者として、「ユーザー」および「認証されたユーザー」と「特定のユーザー」ではありません。さらに、cygwinを理解できませんでした-インストールまたは使用します。(?)
Sam-T

2
Win10の場合、キーをユーザーの家に移動する必要があります -これは完全に機能しました。私はキーへの完全なパスを与え、許可をいじくろうとしていました-何もうまくいきませんでした。
Sam-T

サム-T @リストに自分の名前を見ることができないならば、あなたは押して追加することができEdit...、その後、プレスAdd...し、テキストボックスに名前を入力し"Enter the object names to select"、その後、プレスCheck Namesボタン(を押しOK、別のOK)その後、あなたの名前がで一覧表示されますSecurity]タブ
Supawat Pusavanno

私はおそらくあなたの指示に従って具体的に名前を追加することができます。しかし、私の主な質問は、「すべてを拒否および許可するための正確な権限」です。一方、前述のように、.pemに追加するだけで問題を解決できましたmyuser directory
Sam-T

16

キーの "0x00"アクセス許可要件には1つの例外があります。キーがrootによって所有され、ユーザーが含まれるグループによってグループが所有する場合、そのキーは "0440"になり、そのグループのすべてのユーザーがキーを使用できます。

これはセット "0xx0"のすべての権限で機能すると思いますが、すべてのバージョンですべての組み合わせをテストしたわけではありません。CentOS 6の5.3p1-84で0660を試してみましたが、そのグループはユーザーのプライマリグループではなくセカンダリグループであり、正常に動作します。

これは通常、誰かの個人キーではなく、自動化に使用されるキーで、アプリケーションがキーを乱用したくない状況で行われます。

同様のルールが.sshディレクトリの制限に適用されます。



11

Windows 10では、cygwinのchmodとchgrpでは不十分でした。ファイル->プロパティ->セキュリティ(タブ)を右クリックして、アクティブなユーザーを除くすべてのユーザーとグループを削除する必要がありました。


これは機能している唯一のソリューションです:)ありがとう、私の時間を節約してください
Atul

これを実行した後、通常のWindowsコマンドプロンプトからもsshを実行できることがわかりました。Cygwinを使用する必要はありません。すごい!
Atul

8

これは私のために働いたものです(Mac上)

sudo chmod 600 path_to_your_key.pem 

次に:

ssh -i path_to_your_key user@server_ip

それが役に立てば幸い



4

別のMacからの移行後に同じ問題が発生しました。そして、私のキーでgithubに接続するのをブロックしました。

私は以下のように許可をリセットし、それは今うまく動作します。

chmod 700 ~/.ssh     # (drwx------)
cd ~/.ssh            
chmod 644 *.pub      # (-rw-r--r--)
chmod 600 id_rsa     # (-rw-------)

4

AWSでUbuntu EC2へのWindows 10 sshの「権限がオープンすぎる」エラー

AWSの.pemファイルを使用してUbuntu EC2インスタンスにSSH接続しようとしてこの問題が発生しました。

Windowsでは、このキーを.sshフォルダーの下に作成したキーに配置すると機能しました

C:\Users\USERNAME\.ssh\private_key

Windows 10で権限設定を変更するには:

ファイル設定>セキュリティ>詳細

継承を無効にする

継承されたアクセス許可を明示的なアクセス許可に変換する

管理者以外のすべての権限エントリを削除します

その後、しっかりと接続できました。


4

私(WindowsのUbuntuサブシステムを使用)の場合、エラーメッセージは次のように変わりました。

 Permissions 0555 for 'key.pem' are too open

chmod 400を使用した後。デフォルトのユーザーとしてrootを使用することが理由であることがわかりました。

cmdを使用してこれを変更します。

 ubuntu config --default-user your_username

3

ここに興味深いメッセージがあります。オペレーティングシステムは、秘密鍵が開いている場合にリモート接続を拒否するのに十分スマートです。id_rsaの権限が広く開かれている(読み取り、誰でも編集可能である)リスクを理解しています。

{最初にロックを変更してから、すでに持っているキーでロックを開くことができます}

cd ~/.ssh
chmod 400 id_rsa

複数のサーバー(非運用)で作業している間、ほとんどの人はリモートサーバーをsshで接続する必要があると感じています。サーバー間にssh信頼を作成するために、アプリケーションレベルのコード(jschを使用したjavaの可能性があります)を用意することをお勧めします。この方法で接続すると、パスワードが不要になります。ケースでは、perlがインストールされています-net sshモジュールも使用できます。


1

Ansibleで遊んでいるときにこのエラーに遭遇しました。この問題を解決するために、秘密鍵の権限を600に変更しました。そしてそれはうまくいった!

chmod 600 .vagrant/machines/default/virtualbox/private_key

1

私は自分の秘密鍵に600レベルのアクセス許可を試しましたが、うまくいきました。 chmod 600 privateKey [dev] $ ssh -i privateKey user @ ipが機能しました

chmod 755 privateKey [dev] $ ssh -i privateKey user @ ip 以下の問題が発生しました: 'privateKey'のアクセス許可0755が開きすぎています。秘密鍵ファイルに他人がアクセスできないようにする必要があります。この秘密鍵は無視されます。キー「privateKey」をロード:不正な権限


0
I have got the similar issue when i was trying to login to remote ftp server using public keys..        
To solve this issue initially i have done the following process
    この公開鍵を使用してftpにログインしようとすると、まず、公開鍵の場所を見つけます。最初にキーを作成する必要があり、そのキーのアクセス許可を600に設定するように設定します。
            正しい場所にいることを確認してください。
            ステップ1:
            正しい場所に行く
            ステップ2:
            あなたが正しい場所にいる後
 コマンド: 
     chmod 600 id_rsa

        This has solved my issue.

-1

EC2でVPCを使用していて、同じエラーメッセージが表示されました。パブリックDNSを使用していることに気付きました。プライベートDNSとvolaに変更しました!! 動いた...


Amazonでは、chmod 400とパブリックDNSの使用を推奨しています。ここでのドキュメントを参照してください:docs.aws.amazon.com/AWSEC2/latest/UserGuide/...
DDRI

-2

Win10の場合、LinuxライクなOSの場合、キーをユーザーのホームディレクトリに移動する必要があります。chmodを700ライクまたは600などにする必要があります。


Win10の場合、キーをユーザーの家に移動する必要があります -これは完全に機能しました。私はキーへのフルパスを与えようとしていて、パーミッションをいじっていました-うまくいきませんでした。
Sam-T
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.