web-dev-qa-db-ja.com

リモートコンピューターにSSHで接続しようとするが、パスワードを要求する

リモートコンピューターに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台のリモートコンピュータで機能しないのか教えてもらえますか?

17
JMS1969SF

ssh-copy-idとSELinuxが関係するCentOS 6マシンで同様の bug に遭遇することがよくあります。

ssh-copy-idが承認済みの鍵ファイルを作成するとき、適切な権限を使用してファイルを作成しますが、SELinuxラベルは間違っています。この問題を修正するには、次のコマンドを使用して、ラベルをポリシーのデフォルトに復元します。

restorecon -R ~/.ssh

17

これらが可能な場合は、サーバー側からのデバッグが常にはるかに簡単です。デバッグモードで別のポートでsshdを起動できる場合は、キーが拒否されている理由がすぐにわかります(ホームディレクトリはグループ書き込み可能であると思います)。たとえば、/usr/sbin/sshd -d -p 2222を使用してポート2222のデバッグモードでsshdを開始し、ssh -p 2222 user@remotehostを使用して接続できます。

14
stew

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のパスワードなしのログインがうまくいきました。

3
Matt

この問題は、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
1
Salim Gangji

私はRHEL5でこれを少し前に経験しました(これがあなたが使用しているディストリビューションであるかどうかはわかりません)、ssh-copy-idを使用したときだけであることがわかりました。キーファイルを正しいフォルダにscpしてみてください。もちろん、権限をリセットしてください

1
GeoSword

私の場合、問題はauthorized_keysファイルの誤った形式でした。

フォーマット定義(ssh-rssssh-dss、..)と公開鍵自体の間に改行なしが必要です。

0
helvete

以前、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ファイルソケットのパス

これは、結果に基づくキーの解決に不可欠だと思います。

0
will