私は自分のsshアイデンティティファイルを私の〜/ .ssh /フォルダの中に置いています。私はおそらくそこに約30ファイルを持っています。
私がサーバーに接続するとき、私は使用するアイデンティティファイルを指定します。
ssh -i〜/ .ssh/client1-identity [email protected]
ただし、識別ファイルを指定せずに、次のようにしてください。
ssh [email protected]
私はエラーが出ます
User123の認証失敗回数が多すぎます
これは、識別ファイルが指定されておらず、sshが識別ファイルを見つけることができれば、それらすべてを試すからです。
また、~/.ssh/config
ファイルを編集して次のように指定できることも理解しています。
ホストexample.com PreferredAuthenticationsキーボードインタラクティブ、パスワード
その接続が既知のIDファイルを試行しないようにするため。
そのため、私は自分のアイデンティティファイルを~/.ssh/
ディレクトリの外に移動するか、またはアイデンティティファイル認証を無効にしたい各ホストを設定ファイルで指定することができたと思いますが、SSHを検索しないようにデフォルトに設定します。 IDファイル用それともそれが検索するものを指定するには?
IdentityFile
と一緒にIdentitiesOnly=yes
オプションを使用することができます( ssh_configのmanページ を参照)。そうすれば、どのファイルを探すべきかを指定できます。
この例では、sshはssh_configファイルで与えられたアイデンティティ+(コマンドラインにリストされた4つのアイデンティティ)をのみ調べます(エージェントによって与えられたアイデンティティは無視されます)
ssh -o IdentitiesOnly=yes \
-o IdentityFile=id1.key \
-o IdentityFile=id2.key \
-i id3.key \
-i id4.key \
[email protected]
-i
と-o IdentityFile=
の形式は交換可能です。
user76528の簡単な答えは正しいですが、私はこの問題を抱えていたので、いくらかの詳細が役に立つと思いました。 「なぜsshが私のidentityfile設定オプションを無視するのか」と疑問に思ったのであれば、この解決策について気にする必要がありますか?
まず、ssh_configの他のすべてのオプションとは異なり、sshは最初に見つかったIdentityFile
を使用しません。代わりにIdentityFile
オプションはそのファイルを使用されるIDのリストに追加します。あなたは複数のIdentityFile
オプションをスタックすることができ、そしてsshクライアントはサーバが1つを受け入れるか接続を拒絶するまでそれら全てを試みます。
次に、ssh-agentを使用すると、ssh_configのIdentityFile(または-i)オプションでキーを指定していなくても、sshは自動的にエージェント内のキーを使用しようとします。これがToo many authentication failures for user
エラーが発生する可能性がある一般的な理由です。 IdentitiesOnly yes
オプションを使用すると、この動作が無効になります。
もしあなたが複数のシステムに対して複数のユーザとしてsshを使っているなら、ssh_configのグローバルセクションにIdentitiesOnly yes
を入れ、それぞれのIdentityFile
を適切なHostサブセクションに入れることをお勧めします。
私は一般的にそうします:
$ ssh -o IdentitiesOnly=yes -F /dev/null -i ~/path/to/some_id_rsa [email protected]
オプションは以下のとおりです。
-o IdentitiesOnly=yes
- CLIを介して提供され、$HOME/.ssh
からもssh-agentからも提供されないキーのみを使用するようSSHに指示します。-F /dev/null
- $HOME/.ssh/config
の使用を無効にします-i ~/path/to/some_id_rsa
- 接続に明示的に使用したいキー$ ssh -v -o IdentitiesOnly=yes -F /dev/null -i ~/my_id_rsa [email protected]
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 [email protected]
debug1: Entering interactive session.
Last login: Tue Dec 8 19:03:24 2015 from 153.65.219.15
someserver$
上記の出力で、ssh
はCLI経由でmy_id_rsa
秘密鍵を識別しただけで、それを使用して他のサーバーに接続していることに注意してください。
具体的にはこれらのセクション:
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 [email protected]
IdentitiesOnly yes
を使用することで認められた解決策は、あなたがssh-agentを利用することが決してできないことを意味します。
ssh-agent
を使い続け、 'Too many authentication failure'エラーを避けるために、これを試してください:
自動的にキーをssh-agent
にロードする対話型コンソール起動スクリプトを削除します。
クライアントのssh設定にAddKeysToAgent yes
を追加してください。これにより、最初の接続時にパスフレーズの入力を求められますが、その後エージェントにキーを追加してください。
認証が多すぎるというエラーが発生した場合は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
このようなクライアントの呼び出しはエージェントとの通信に失敗し、〜/ .ssh /のファイルとして、または-iを使用してコマンドラインで指定されたものとして利用可能なIDのみをサーバーに提供できます。
debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused
〜/ .ssh/configファイルの最後にこれを追加して、非構成サーバーの使用キーを防止します。
ホスト *
IdentitiesOnly = yes
あなたは(ほとんど)ずっと答えを持っていました:
Host *
PreferredAuthentications keyboard-interactive,password
私のために働きました。