☰

SSH接続のトラブルシューティング

tag-icon • tag-icon ssh fedora troubleshooting
SSH接続のトラブルシューティング

私はSSHを介して新しいサーバーに接続する問題を解決する方法に関するヒントを探しています。 SSHがパスワードを要求せずにローカル秘密鍵を使用して認証する秘密鍵認証を使用して接続しようとしたときに問題が発生しました。

を実行すると、ssh root@newserverパスワードの入力を求められず、すぐに接続に成功します。代わりにを実行すると、ssh user@newserver秘密鍵認証の試行が失敗し、パスワードの入力を求められます。後者がなぜ失敗するのか混乱しています。これをデバッグするにはどうすればよいですか？

私が試したこと：

  • 私は2回確認しました/root/.ssh/authorized_keys。/home/user/.ssh/authorized_keysどちらも同じで、どちらも私の公開鍵を含みます。

  • 権限/root/.sshと/home/user/.sshディレクトリを再確認しましたnewserver。すべてが大丈夫に見えます。とにかく、権限は両方とも同じです。

  • 私は2つの異なるクライアントでログインしようとしましたが、両方のクライアントで同じ動作を見たので、これはクライアントに限定されていないと思います。両方のクライアントから別のサーバーに正常にログインできます。

  • /usr/sbin/sshd -d -p 2323新しいサーバーで実行しようとし、ssh -p 2323 root@newserverを使用して接続しましたssh -p 2323 user@newserver。謎の部分は次のとおりです。sshdコマンドラインから手動で実行すると、秘密鍵認証を介してもログインできますが、システム標準を使用しようとすると秘密root鍵認証を介してのみログインできますが、ログインすることはできません。usersshdrootuser

  • 私は逃げたssh -v。私は悟りを得ることができるものを見ませんでした：それでssh -v root@newserver、私はそれを得ます

    debug1: Offering DSA public key: /home/user/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 433

    それでssh -v user@newserver私は得る

    debug1: Offering DSA public key: /home/daw/.ssh/id_dsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

    さらに追加しても-v洞察を得ることはできませんssh -vvvvv bingen.cs.berkeley.edu。

    debug1: Offering DSA public key: /home/daw/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

    したがって、秘密鍵認証によるログイン試行が失敗する理由についての説明はありません。

Fedora 21、openssh-6.6.1p1-11.1.fc21.x86_64。

答え1

私の考えでは、nluがあなたに正しい方向を教えてくれたと思います。

通常、SSHの問題を追跡するためのより良い方法は、sshdサーバー側でSSHを停止してから$(which sshd) -d。

ほとんどすべての場合、これはより意味のあるエラーメッセージを提供します。

更新：申し訳ありません。すでにこれを行っています。

cliのsshdとサービスのsshdの間にSELINUXという1つの違いがあるようです。

CLIではそれほど厳しくありません。 selinuxをアクティブにしましたか？もしそうなら、se-logs/設定をチェックしてください！

答え2

また、/home/user/.ssh/authorized_keysの所有権と権限も確認する必要があります。

答え3

私はSELinuxのファイル権限の問題でした~/.ssh/。外部ドライブに保存されているバックアップからファイルをコピーしましたが、別のラベルを受け取り、誤ったラベルが保持されているようです。

私はもっ​​とよく知っていたはずだった。権限の問題である可能性がある不明なエラーが発生した場合は、必ずSELinuxを確認してください。

修正: restorecon -r /home/user/.ssh。

関連情報