リモートコンピューターにSSHで接続しようとしていますが、パスワードを要求しています。
SElinuxを実行しているコンピュータがいくつかあり、そのうちの1つだけがパスワードなしでsshを使用するのに苦労しています。
私はssh-copy-idを実行し、.ssh/authorized_keysで自分のキーを確認できます。
私は./ssh/*内のすべてのファイルをchmod 700 .sshおよびchmod 600
私がssh -vを実行すると、これは私の出力です:
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to wcmisdlin05 [10.52.208.224] port 22.
debug1: Connection established.
debug1: identity file /home/jsmith/.ssh/identity type -1
debug1: identity file /home/jsmith/.ssh/id_rsa type 1
debug1: identity file /home/jsmith/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
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: Host 'wcmisdlin05' is known and matches the RSA Host key.
debug1: Found key in /home/jsmith/.ssh/known_hosts:9
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
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: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_501' not found
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_501' not found
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Next authentication method: publickey
debug1: Offering public key: /home/jsmith/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/jsmith/.ssh/identity
debug1: Trying private key: /home/jsmith/.ssh/id_dsa
debug1: Next authentication method: password
誰かがなぜこの1台のリモートコンピュータで機能しないのか教えてもらえますか?
ssh-copy-id
とSELinuxが関係するCentOS 6マシンで同様の bug に遭遇することがよくあります。
ssh-copy-id
が承認済みの鍵ファイルを作成するとき、適切な権限を使用してファイルを作成しますが、SELinuxラベルは間違っています。この問題を修正するには、次のコマンドを使用して、ラベルをポリシーのデフォルトに復元します。
restorecon -R ~/.ssh
これらが可能な場合は、サーバー側からのデバッグが常にはるかに簡単です。デバッグモードで別のポートでsshdを起動できる場合は、キーが拒否されている理由がすぐにわかります(ホームディレクトリはグループ書き込み可能であると思います)。たとえば、/usr/sbin/sshd -d -p 2222
を使用してポート2222のデバッグモードでsshdを開始し、ssh -p 2222 user@remotehost
を使用して接続できます。
SElinuxについて言及したポスターが私の問題の頭を釘付けにしました、私はselinuxを使いたくありませんが、それを無効にするのを忘れており、サーバーは起動時にselinuxを有効にすることを思い付きました。
ssh -v
デバッグに役立ちました。キーは受け入れられます:
debug1: Found key in /var/lib/amanda/.ssh/known_hosts:19
debug1: ssh_rsa_verify: signature correct
そして、私はエラーが出ます
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_502' not found
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_502' not found
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_502' not found
私の修正は、setenforce 0
でselinuxをオフにしてから、/ etc/selinuxで無効にすることでした。次に、sshのパスワードなしのログインがうまくいきました。
この問題は、SE-Linuxラベルが変更されたことが原因である可能性があります(例:docker bind-mountsの:Zまたは:zオプション)。
これらを実行してみてください:
chcon --recursive unconfined_u:object_r:user_home_dir_t:s0 ${HOME}
chcon --recursive unconfined_u:object_r:ssh_home_t:s0 ${HOME}/.ssh
私はRHEL5でこれを少し前に経験しました(これがあなたが使用しているディストリビューションであるかどうかはわかりません)、ssh-copy-idを使用したときだけであることがわかりました。キーファイルを正しいフォルダにscpしてみてください。もちろん、権限をリセットしてください
私の場合、問題はauthorized_keys
ファイルの誤った形式でした。
フォーマット定義(ssh-rss
、ssh-dss
、..)と公開鍵自体の間に改行なしが必要です。
以前、sshとキーファイルで問題がありました。その際、IDキーの名前を "id_rsa
"に変更すると役立ちました。残念ながら、サーバーごとに異なるキーがあります。そのため、そのアプローチの有用性は限られています。一回限りで役立つかもしれません。
第二に、今日、私はこのエラーを1つのXTermセッションでのみ発生し、同じサーバー/ホースマシンへの他の6つのxtermセッションですべてがうまく機能します。そこで、両方のセッションでenv
からの出力を比較しました。これはワーキングセッションであることがわかりましたが、これは非ワーキングセッションにはありませんでした。
SSH_AUTH_SOCK=/run/user/1001/keyring/ssh
その割り当てを非稼働セッションに貼り付けました。
export SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
ssh user@Host
... Welcome ...
言い換えれば、その解決策は私にとってうまくいきました。
SSH_AUTH_SOCKETを少しチェックしました。この答えから:
エージェントが他のプロセスとの通信に使用するUNIXファイルソケットのパス
これは、結果に基づくキーの解決に不可欠だと思います。