リモートコンピューターに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台のリモートコンピューターで動作しない理由を教えてください。

SELinux が関係するCentOS 6マシンでよく似たバグに遭遇しましたssh-copy-id。

ssh-copy-id許可されたキーファイルを作成するとき、適切なパーミッションで作成されますが、SELinuxラベルが間違っています。この問題を解決するには、次のコマンドを使用してラベルをポリシーのデフォルトに復元します。

restorecon -R ~/.ssh

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

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、/ etc / selinuxでselinuxをオフにしてから無効にすることでした。それから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を少しチェックしました。この答えから：

• SSH_AUTH_SOCKはどのようにセットアップされ、ssh-agentで使用されますか？

エージェントが他のプロセスとの通信に使用するUNIXファイルソケットのパス

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

debug1：公開キーの提供：/home/jsmith/.ssh/id_ rsa

...

debug1：秘密鍵の試行：/home/jsmith/.ssh/id_ dsa

秘密/公開鍵が単に一致しないように思えます。キー名から、公開キーはRSAキーであり、秘密キーはDSAであることがわかります。

scpサーバーへの新しいペアと公開キーを生成してみてください。

./sshとユーザーのホームディレクトリ、キーファイル、authorized_keysファイルの権限を確認することをお勧めします。他の誰もいないので、sshパスワードレス接続を機能させるには、所有者がそこに読み書きできるようにする必要があります。これは、ソースマシンとターゲットマシンの両方に関係します。正直に言うと、大きな権利があっても機能することもありますが、そうではありません。