解決策 1:
はい、あなたが説明したとおりにできます。
[email protected] ~$ ssh-add -l 4096 10:b3:fd:29:08:86:24:a6:da:0a:dd:c6:1e:b0:66:6a id_rsa (RSA) [email protected] ~$ ssh [email protected] motd message, etc. [email protected] ~$
解決策 2:
余談ですが……
リモート サーバーに常に同じユーザー名を使用している場合は、ssh 構成にホストを追加すると便利な場合があります。
Host remotesystem
User baruser
そうすれば、ログイン時にユーザー名を指定することを覚えておく必要がなくなり、将来キーで問題が発生したときにそれを除外できます。
解決策 3:
ローカル ユーザー名は実際には重要ではありません (秘密鍵がローカル ユーザーのホーム ディレクトリ内に存在する必要があることを除けば)。キーをリモート ユーザーの authorized_keys にコピーするだけです。
解決策 4:
ssh 関連の問題がある場合、最初に行うことは、クライアントの冗長性を上げることです:
ssh [email protected] -vvv
これで問題の原因を特定できない場合は、サーバーのログ レベルを変更し、デーモンを再起動する必要があります。
LogLevel DEBUG3
/var/log/auth.log (または ssh がログに記録するように構成されている場所) でデバッグ出力を見つける必要があります。問題を見つけたら、見つけた方法に戻すことを忘れないでください。
解決策 5:
両方のマシンの .ssh ディレクトリのアクセス許可は、かなり正確です。通常、これは .ssh ディレクトリで 700、ホーム ディレクトリで最大 755 を意味します。 .ssh ディレクトリ内のすべてのファイルで 600 に加えて。
リモート システムのユーザーが root の場合は、root が ssh できることを確認してください。 (sshd_config の PermitRootLogin) とその公開鍵 (PubkeyAuthentication)、および必要に応じて RSA (RSAAuthentication) が有効になっています。