新しいユーザーアカウントがコマンドを介してRSAキー認証を使用してCentos 7サーバーにSSHで正常に接続できないことをデバッグしようとしています。
ssh theuser@theserver
以下の観察が可能です。
- ユーザーアカウントが存在し、ロックされていません。
- ユーザーのホームフォルダには、Authorized_keysファイル(600権限)を含む.sshディレクトリ(700権限)が含まれています。
- Authorized_keys ファイルには、ローカルコンピュータの公開鍵のコピーが含まれています。
- ローカルシステムの ~/.ssh/config ファイルは、そのサーバーの正しいキーファイルを指します。
- 鍵認証が失敗した場合は、ユーザーパスワードを入力してsshを正常に実装できます。
- 別のユーザーアカウントを使用して公開鍵を介してSSHを実装できます。
- ユーザーがキーを拒否した場合、/var/log/secure ファイルには何も記録されません。
私の同僚と私が詰まったのですが、この問題の原因を見つけるために取るべき次のステップを提案してください。
編集:ssh -vvv出力を含む
debug1: Host 'theserver' is known and matches the ECDSA host key.
debug1: Found key in /Users/ambulare/.ssh/known_hosts:20
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: /Users/ambulare/.ssh/server_isr_id_rsa_ambulare (0x7fc#obfuscated#), explicit
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/ambulare/.ssh/server_isr_id_rsa_ambulare
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
答え1
@DevilaNの提案のおかげで問題は解決されました。
ssh-copy-id を試行すると、「authorized_keys に対する権限の拒否」エラーが返されます。これは権限エラーでしたので、このファイルにユーザーの所有権を設定しましたが(元の質問のように)、Authorized_keysファイルの所有権と権限を再確認する操作に戻りました。設定 これにより、所有権が「root」に変更されました。
単純な所有権の問題です。
chown theuser:theuser authorized_keys
チャジャン、SSHが動作しています。
Google検索でこの回答を見つけた人の場合:間違ったユーザーが認証キーファイルを所有している場合、ssh-copy-idを実行するまでどこでも許可エラーを返したり記録したりせずにsshログイン試行が自動的に失敗する同じです。 。