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

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に指示する方法はありますか？アイデンティティファイル？または、検索するものを指定するには？

IdentitiesOnly=yesオプションと一緒に使用できますIdentityFile（ssh_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=は互換性があります。

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サブセクションに入れることをお勧めします。

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

$ 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$

上記の出力でsshはmy_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).

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

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

ssh -o PreferredAuthentications=password user@example.com

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
   

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

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

Host *
PreferredAuthentications keyboard-interactive,password

私のために働いた。

これを~/.ssh/configファイルの最後に追加して、非構成サーバーの使用キーを防止します。

Host *
IdentitiesOnly=yes