すべてのIDファイルを自動的に試行しないようにSSHを構成するにはどうすればよいですか?


101

ssh IDファイルを〜/ .ssh /フォルダーに入れています。おそらく約30個のファイルがあります。

サーバーに接続するとき、使用するIDファイルを次のように指定します

ssh -i〜/ .ssh / client1-identity client1@10.1.1.10

ただし、IDファイルを指定せず、次のようなものを使用する場合:

ssh user123@example.com

エラーが表示されます

user123の認証エラーが多すぎます

これは、IDファイルが指定されておらず、sshがIDファイルを見つけることができる場合、それらすべてを試行するためです。

また、~/.ssh/configファイルを編集して次のように指定できることも理解しています。

ホストexample.com
PreferredAuthenticationsキーボードインタラクティブ、パスワード

その接続が既知のIDファイルを試行するのを防ぐため。

だから、~/.ssh/ディレクトリの外にIDファイルを移動したり、設定ファイルでIDファイル認証を無効にする各ホストを指定することはできますが、検索せずにデフォルトを購入するようにSSHに指示する方法はありますか?アイデンティティファイル?または、検索するものを指定するには?


4
再 "私はそれが理由です..."- ssh -v確かに見つけるために使用します。
悲しみ

回答:


101

IdentitiesOnly=yesオプションと一緒に使用できますIdentityFilessh_configのmanページを参照)。これにより、検索するファイルを指定できます。

この例では、sshはssh_configファイルで指定されたID +コマンドラインにリストされている4つのID のみを調べます(エージェントによって提供されたIDは無視されます)。

ssh -o IdentitiesOnly=yes \
    -o IdentityFile=id1.key \
    -o IdentityFile=id2.key \
    -i id3.key \
    -i id4.key \
    user123@example.com

フォーム-i-o IdentityFile=は互換性があります。


7
例としては、いいだろう
rubo77

1
そうではありませんか:(IdentitiesOnly yes「=」なし)?
ディミトリオスミストリオティス16

3
ssh_configのmanページによると@DimitriosMistriotis、いずれかの許容です:Configuration options may be separated by whitespace or optional whitespace and exactly one '='; the latter format is useful to avoid the need to quote whitespace when specifying configuration options using the ssh, scp, and sftp -o option.
ニック・Anderegg

IdentitiesOnly常に機能するとは限らないため、ホストを明確に除外する必要があります。superuser.com/questions/859661/を
aexl

79

user76528の短い答えは正しいですが、私はこの問題を抱えていたので、いくつかの詳細化が役立つと思いました。「なぜsshが私のidentityfile設定オプションを無視するのか」と疑問に思っているなら、この解決策を気にするかもしれません。

まず、ssh_configの他のすべてのオプションとは異なり、sshは最初IdentityFileに検出したものを使用しません。代わりに、IdentityFileオプションはそのファイルを使用されるIDのリストに追加します。複数のIdentityFileオプションをスタックすることができ、sshクライアントは、サーバーがオプションを受け入れるか接続を拒否するまで、それらすべてを試行します。

次に、ssh-agentを使用する場合、sshは、ssh_configのIdentityFile(または-i)オプションでキーを指定していない場合でも、エージェントでキーを自動的に使用しようとします。これは、Too many authentication failures for userエラーが発生する一般的な理由です。IdentitiesOnly yesオプションを使用すると、この動作が無効になります。

複数のシステムに複数のユーザーとしてsshする場合IdentitiesOnly yes、ssh_configのグローバルセクションに入れ、それぞれIdentityFileを適切なHostサブセクションに入れることをお勧めします。


5
うまく説明してくれてありがとう。そのパラメーター 'IdentitiesOnly'がTakeOnlyWhatIExplicitlySpecifyThenFailoverToPasswordを意味することは明らかではありません。そして、どうやら、。/ ssh / id_rsaキーはまだリストされています。
リムバス

パッティングIdentitiesOnly yesはssh_configのグローバルセクションでは、私のためにそれをやったことです。ありがとう!
jamix

1
詳細なコメントありがとうございます。以前Host * \ IdentityFile ~/.ssh/mykeyは構成オプションとして(改行の場合は '\')を使用していましたが、最初は特定のサイトに別のエントリがあること、たとえばの代わりHost special \ IdentityFile ~/.ssh/specialkey \ IdentitiesOnly yesに供給mykeyを続けることは奇妙に思えましたspecialkey。IdentityFileエントリが評価の順序でスタックされ、最後に定義されたエントリが使用されることを(あなたの答えから)気づくまでは、確かに明確ではありませんでした。削除IdentityFile ~/.ssh/mykeyすることで問題が解決し、正しい単一のキーが使用されました。
ライダー

1
これを試す前に、git pull/pushコマンドがエージェントにロードされたすべてのIDを試していることに気付きました。ある時点でキーが多すぎるまでは問題ではありませんでした。
sdkks

21

私は一般的に次のようにします:

$ ssh -o IdentitiesOnly=yes -F /dev/null -i ~/path/to/some_id_rsa root@server.mydom.com

オプションは次のとおりです。

  • -o IdentitiesOnly=yes-SSHに、CLI経由で提供されるキーのみを使用し、$HOME/.sshssh-agentまたは
  • -F /dev/null -の使用を無効にします $HOME/.ssh/config
  • -i ~/path/to/some_id_rsa -明示的に接続に使用するキー

$ ssh -v -o IdentitiesOnly=yes -F /dev/null -i ~/my_id_rsa root@someserver.mydom.com
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /dev/null
debug1: Connecting to someserver.mydom.com [10.128.12.124] port 22.
debug1: Connection established.
debug1: identity file /Users/sammingolelli/my_id_rsa type 1
debug1: identity file /Users/sammingolelli/my_id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA f5:60:30:71:8c:a3:da:a3:fe:b1:6d:0b:20:87:23:e1
debug1: Host 'someserver' is known and matches the RSA host key.
debug1: Found key in /Users/sammingolelli/.ssh/known_hosts:103
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammingolelli/my_id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to someserver.mydom.com ([10.128.12.124]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
Last login: Tue Dec  8 19:03:24 2015 from 153.65.219.15
someserver$

上記の出力でsshmy_id_rsa、CLI経由でのみ秘密鍵を識別し、それを使用してsomeserverに接続していることに注意してください。

特にこれらのセクション:

debug1: identity file /Users/sammingolelli/my_id_rsa type 1
debug1: identity file /Users/sammingolelli/my_id_rsa-cert type -1

そして:

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammingolelli/my_id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).

1
おかげで、これが唯一の完全なソリューションです。どうやら、-F /dev/null他の答えの欠けている部分です。
leden

10

多くのキーがあるシナリオでは、常に「Too many Authentication Failures」エラーが発生します。パスワードがあり、単にパスワードを使用してログインする場合は、次のようにします。

パスワード認証のみを使用し、公開キーを使用せず、やや誤解を招く「キーボードインタラクティブ」(パスワードを含むスーパーセット)を使用しないようにするには、コマンドラインからこれを実行できます。

ssh -o PreferredAuthentications=password user@example.com

7

IdentityFileを使用しますが、ssh-agentを使用してパスフレーズの再プロンプトを回避します

使用の受け入れられた解決策はIdentitiesOnly yes、ssh-agentを利用できないことを意味し、キーをロードするときにパスフレーズのプロンプトが繰り返し表示されます。

使用ssh-agentし続け、「認証エラーが多すぎます」エラーを回避するには、次を試してください。

  1. にキーを自動的にロードする対話型コンソール起動スクリプトを削除しssh-agentます。

  2. AddKeysToAgent yesクライアントのssh設定に追加します。これにより、最初の接続時にパスフレーズの入力が求められますが、その後、エージェントにキーが追加されます。

  3. ssh-add -D「認証が多すぎます」エラーが発生した場合に使用します。これは、ssh-agentキャッシュを単に「リセット」(削除)します。次に、同じセッション内で接続を再試行します。パスフレーズの入力を求められ、受け入れられると、エージェントに追加されます。エージェントにはキーが1つしかないため、接続が許可されます。ssh-agentは、同じセッション中の今後の接続のために、再プロンプトを避けるためにまだそこにあります。

    Host ex example.com
       User joe
       HostName example.com
       PreferredAuthentications publickey,password
       IdentityFile /path/to/id_rsa
       AddKeysToAgent yes
    

キーチェーンに追加されたキーを受け入れますか?
vfclists

2

sshクライアントとはssh-agent、名前がSSH_AUTH_SOCK環境変数(クライアントが起動時に設定する)によってクライアントに指定されているUnixドメインソケットを介して通信しています。

したがって、クライアントの1回の呼び出しでエージェントを照会しないようにするには、この変数を空の文字列などの無効な値に明示的に設定できます。

$ SSH_AUTH_SOCK= ssh user@server

このようなクライアント呼び出しは、エージェントとの通信に失敗し、でファイルとして使用可能なID ~/.ssh/、またはを使用してコマンドラインで指定されたIDのみを-iサーバーに提供できます。

debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused

これは素晴らしい答えです。gitのような「内部」でSSHを使用するコマンドを使用している場合は、簡単で機能します。残念ながら、これ以上賛成できません。
rsuarez

1

ほぼすべての回答がありました:

Host *
PreferredAuthentications keyboard-interactive,password

私のために働いた。


8
質問では、使用する公開鍵を制限する方法について尋ねました。この答えは公開鍵認証を完全に無効にします。
chrishiestand

1
私がグーグルで答えていたので+1しました、ありがとう@Henry Grebler
matiu

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.