web-dev-qa-db-ja.com

自分のサーバーからロックアウト:ssh経由で接続するとすぐに「認証失敗が多すぎます」

ペットプロジェクト用のAWS EC2 Ubuntuインスタンスがあります。ある日ログインしようとすると、次のエラーが発生します。

~$ ssh -i"/home/kona/.ssh/aws_kona_id" [email protected] -p22 
Enter passphrase for key '/home/kona/.ssh/aws_kona_id': 
Received disconnect from [IP address] port 22:2: Too many authentication failures
Disconnected from [IP address] port 22
~$

konaは、このサーバーで有効になっている唯一のアカウントです

サーバーを再起動し、IPアドレスを変更して、待機しました。

編集:

kona@arcticjieer:~$ ssh -o "IdentitiesOnly yes" -i"/home/kona/.ssh/aws_kona_id" -v [email protected] -p22 
OpenSSH_8.1p1 Debian-1, OpenSSL 1.1.1d  10 Sep 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to ec2-3-17-146-113.us-east-2.compute.amazonaws.com [3.17.146.113] port 22.
debug1: Connection established.
debug1: identity file /home/kona/.ssh/aws_kona_id type -1
debug1: identity file /home/kona/.ssh/aws_kona_id-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.1p1 Debian-1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
debug1: match: OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug1: Authenticating to ec2-3-17-146-113.us-east-2.compute.amazonaws.com:22 as 'kona'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: Host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server Host key: ecdsa-sha2-nistp256 SHA256:D3sIum9dMyyHNjtnL7Pr4u5DhmP5aQ1jaZ8Adsdma9E
debug1: Host 'ec2-3-17-146-113.us-east-2.compute.amazonaws.com' is known and matches the ECDSA Host key.
debug1: Found key in /home/kona/.ssh/known_hosts:41
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/kona/.ssh/aws_kona_id  explicit
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/kona/.ssh/aws_kona_id
Enter passphrase for key '/home/kona/.ssh/aws_kona_id': 
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
[email protected]: Permission denied (publickey).
kona@arcticjieer:~$ 
26
Arctic Kona

このエラーは通常、ssh-agentに読み込まれたキーが多すぎるがあることを意味します。

説明:sshクライアントは、ssh-agentで指定されたキーを使用する前に、-i aws_kona_idのすべてのキーを1つずつ使用しようとします。はい、直感に反しています。そのような各試行は認証失敗としてカウントされ、デフォルトでは5回の試行のみがSSHサーバーで許可されているため、次のエラーが表示されます。認証失敗が多すぎます

ssh -vで試行されたID(キー)を表示できます。

解決策は、コマンドラインで指定されたIDのみを使用するようにsshに指示することです。

ssh -o "IdentitiesOnly yes" -i ~/.ssh/aws_kona_id -v [email protected]

それでも解決しない場合は、そのコマンドの出力をここに投稿してください。

48
MLu

この場合、MLuの答えはおそらく正しいと思います。これを検証する方法は、サーバーに正しいキーを指定してコマンドラインのsshコマンドを実行することです。

ssh -i "keyfile.pem" [email protected]

それが機能せず、「サーバーからロックアウトされました、助けて!」という一般的なケースでは、一般的に推奨されるアプローチは、ボリュームをデータボリュームとして別のインスタンスにマウントすることです。

  1. EC2サーバーを停止します。
  2. ボリュームをマウント をデータボリュームとして新しいインスタンスにマウントします。
  3. 必要な調査または修復を行います(ログを確認し、キーを追加するなど)。これには、新しいユーザーと新しいキーの作成、ファイルシステム上のファイルの変更などが含まれます。
  4. ボリュームをルートボリュームとして元のインスタンスにマウントします。

アクセスできるまで繰り返します。アクセスできない場合は、少なくともデータにアクセスできます。

29
Tim

デフォルトでは、SSHは使用可能なすべてのSSHキーを試行します。それは「ランダムな」順序で行われます。 -iオプションを指定すると、SSHはそのキーファイルを試行するキーのリストに追加するように指示されます。

しない

  • その鍵のみを使用するようにSSHを制限する
  • sSHにそのキーを試すように伝えます最初に

何が起こっているのか(多くのキーを使用する場合はかなり多い)は、SSHが機能しないランダムなキーをいくつか試し、サーバーがクライアントからの認証試行の受け入れを停止することです。

SSHに「onlythis key」を使用するように指示する場合は、IdentitiesOnly yesオプションを指定する必要があります。

ssh -o "IdentitiesOnly yes" -i"/home/kona/.ssh/aws_kona_id" [email protected] -p22 

IdentitiesOnly yesは、明示的に指定されたキーのみを使用するようにSSHに指示します(この場合、-iを使用して指定されたキーのみ)。

これが、さまざまなホストにカスタムキーを使用する場合、常に常にホスト構成を.ssh/configで定義するためです。これにより、簡単なエイリアスを使用できるようになり、さらに重要なことに、IdentitiesOnly yesと、この種のミスを回避するために使用するキーを指定できます。

Host kona.server
    Hostname server.akona.me
    IdentityFile ~/.ssh/aws_kona_id
    IdentitiesOnly yes
    Port 22
    User kona

上記の.ssh/configを使用すると、次のように簡単にサーバーにログインできます。

$ ssh kona.server
26
Giacomo Alzetta

追加した詳細な出力は、Permission deniedに対して~/.ssh/aws_kona_idを取得していることを示しています。

これはToo many authentication failuresとはまったく別の問題です。

おそらく、あなたのaws_kona_idはユーザーにとって適切なキーではありません(そのため、ssh-agentから他のすべてのIDを試し続けました)、またはデフォルトのEC2ユーザーアカウントを使用する必要があります。 ec2-userまたはubuntuまたは何を持っていますか。

それらのアカウントを試すか、konaユーザーに適切なキーを見つけてください。

5
MLu

Ubuntu EC2インスタンスには、sshキーでインストールされたubuntuユーザーアカウントがあります。

このアカウントを削除しなくても、引き続き接続できます。

ssh -i "/home/kona/.ssh/aws_kona_id" [email protected]

Sudo -iの後でアカウントの問題を修正し、/home/kona/.ssh/authorized_keysを調査してください

1
profy