SSHキー認証が失敗する

私は制御できないCentOSサーバーにsshしようとしています。管理者はサーバーに公開鍵を追加し、障害は私にあると主張していますが、何が間違っているのかわかりません。

.sshの構成：

tim@tim-UX31A:~$ cat ~/.ssh/config
User root
PasswordAuthentication no
IdentityFile ~/.ssh/id_rsa

私のキーファイルの許可：

tim@tim-UX31A:~$ ls -l ~/.ssh/id_rsa*
-rw------- 1 tim tim 3326 Okt 20 17:28 /home/tim/.ssh/id_rsa
-rw-r--r-- 1 tim tim  746 Okt 20 17:28 /home/tim/.ssh/id_rsa.pub

私が理解できない接続ログ：

tim@tim-UX31A:~$ ssh -vvv root@10.0.12.28
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /home/tim/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "10.0.12.28" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 10.0.12.28 [10.0.12.28] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 10.0.12.28:22 as 'root'
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,ecdsa-sha2-nistp256
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: MACs ctos: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: 
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug1: Host '10.0.12.28' is known and matches the ECDSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:3
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619ab2b0), explicit, agent
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619bcfa0), agent
debug2: key: tim@Tim-UX31A-Debian (0x55ee619b9370), agent
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: tim@Tim-UX31A-Debian
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

これにより、通常、サーバー側でのほとんどのSSH認証キーのアクセス許可の問題が解決されます。誰かがアクセス許可に追加の変更を加えなかったと仮定します。

sudo chown yourusername:yourusername /home/yourusername/ -R
sudo chmod o-rwx /home/yourusername/ -R

管理者が.ssh /ディレクトリまたは.ssh / authorized_keysファイルをルートとして作成した場合（これが最も一般的な方法です）、別のユーザーが（rootであっても）ファイルを所有することは許可されません。

Userify（免責事項：共同設立者）はこれをまったく同じ方法で自動的に行います 。https://github.com/userify/shim/blob/master/shim.py#L285

2つのサーバーでまったく同じ問題が発生しました。Debianストレッチを実行しているLinuxとNAS（Synology DS715）

どちらの場合も、サーバー上のホームディレクトリのアクセス許可が間違っていたことが判明しました

サーバー上のauth.logはとても役に立ちました

Authentication refused: bad ownership or modes for directory /home/cyril

Linuxでは、書き込み/グループビットがオン（drwxrwxr--x）だったので、少なくとも書き込みグループ（chmod gw〜/）を削除する必要がありましたが、その後動作しました

Synologyでは、何らかの理由で、スティッキービットがありました

drwx--x--x+ 4 toto users 4096 Jan 6 12:11 /var/services/homes/toto

私はそれを変更しなければなりませんでした

chmod -t ~/

パスワードなしで接続できました

CentOS 7を使用している場合、sshdを使用している他のLinux OSにも適用されると確信しています。ルートアクセスを使用すると、認証が失敗する理由について詳しく判断できます。これをする：

1. sshdのログを有効にします。 vi /etc/ssh/sshd_config
2. ロギングのコメント解除：

SyslogFacility AUTH LogLevel INFO

1. LogLevel INFOをLogLevel DEBUGに変更します
2. 保存して終了
3. sshdを再起動します systemctl restart sshd
4. メッセージファイルを見る tail -l /var/log/messages
5. 別の端末を使用して、sshで接続を試みます
6. sshで接続しようとしました
7. 正確な原因については、認証ログを確認してください

たとえば、上記と同じ問題がいくつか発生していました。

Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys

これらの手順を使用して、問題がauthorized_keysファイルの権限であることを確認できました。ユーザーの認証キーファイルでchmodを644に設定することで、問題は修正されました。

.sshフォルダーのアクセス許可が正しくコピー+貼り付けされていないようです。もう一度追加してもらえますか？

厳格モードが有効になっ.sshている場合は、次の権限が正しいことを確認する必要があります。

• .ssh/ パーマが必要です 0700/rwx------
• .ssh/*.pub ファイルは 644/rw-r--r--
• .ssh/* （.sshの他のファイル） 0600/rw-------

許可の観点からあなたはどのように見えますか？

誰かがこの答えに出くわした場合に備えて-私のシナリオではどの推奨事項も機能しませんでした。結局、問題はパスワードが設定されていないアカウントを作成していたことです。を使用usermod -p "my password" usernameしてパスワードを設定し、強制的にアカウントのロックを解除すると、usermod -U usernameすべてがうまくいきました。

私は同様の問題を抱えていましたが、ssh接続は~/.ssh/id_rsa予期せずに停止する前にキーを試行します：

debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

私の場合、それは.sshディレクトリにある古い公開鍵ファイルが原因でした：

[gitlab-runner@validation-k8s-1 ~]$ ll .ssh/id_rsa*
total 16
-rw------- 1 gitlab-runner gitlab-runner 1675 Sep 18 18:02 id_rsa      --> new private key
-rw-r--r--. 1 gitlab-runner gitlab-runner  423 Jun 12 13:51 id_rsa.pub --> old public key

ディレクトリid_rsa.pubから移動/削除することで.ssh問題を解決しました。

私が理解していることから：クライアント側に公開鍵が存在する場合、SSH 1stはそれに対して秘密鍵を検証します。失敗すると、秘密鍵を使用してリモートで接続しようとしません。

：私はopensshのメーリングリストに電子メールを送ったhttps://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html。

この問題が発生しました。.sshファイルの権限と所有権はすべて正しいものでした。/ var / log / messagesで次を見つけました。

Mar 29 15:45:36 centos70 setroubleshoot: SELinux is preventing /usr/sbin/sshd from read access on the file authorized_keys. For complete SELinux messages run: sealert -l 05963b94-f318-4615-806c-b6c3a9066c82

SO、セキュリティを気にしない開発者vmのソリューションは、selinuxを無効にすることです。/ etc / sysconfig / selinuxを編集し、SELINUX = disabledを変更して再起動します。

この問題も発生しました。私の環境ではsetroubleshootが機能していないようで、/ var / log / messagesにそのようなログレコードはありませんでした。SELinuxを無効にすることは私にとって選択肢ではなかったので、

restorecon -Rv ~/.ssh

その後、rsaキーによるログインは正常に機能しました。

念のためこれは誰かを救うことにもなります。Ubuntu 18.04マシンから2台のCentOS 7サーバーにキーをコピーしようとしていました。私は使ったssh-copy-idそれらを転送していました。1つは機能し、もう1つは機能しませんでした。だから私はすべての許可デバッグを行ったが何も見つからなかった。最後に/etc/ssh/sshd_config、両方のサーバーでファイルを取得し、それらを1行ずつステップ実行しました。最後に私はそれを見つけた。おそらく私が仕事に就くずっと前に誰かが修正したものだ。

一読： AuthorizedKeysFile .ssh/authorized_keys

そしてもう一つ読みました： AuthorizedKeysFile ~/.ssh/authorized_keys、それは私のキーを受け入れていなかったサーバーにありました。明らかに、2つのファイルを調べて、デフォルトの検索パターンに先頭の行が含まれていないことを示すコメントに注目して、~/削除してsshdを再起動しました。問題が解決しました。

次のように終わるクライアント側のエラーログ：

Enter passphrase for key '/root/.ssh/id_rsa':
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
root@x.x.x.x's password:

sshd構成ファイルに次が含まれている場合、ルートログインのサーバー側（リモート）制限が原因である可能性があります。

PermitRootLogin: no

ログを有効にするというJonCavの提案は、このような問題のデバッグに役立ちました。クライアント側のデバッグスピューは非常に役に立ちませんでしたが、sshdサーバーのsshd_configファイルに以下を配置します。

SyslogFacility AUTH
LogLevel DEBUG

有用なログメッセージを生成することになりました：

Jul 19 19:16:38 500265-web1 sshd[21188]: Found matching RSA key: ...
Jul 19 19:16:38 500265-web1 sshd[21188]: ROOT LOGIN REFUSED FROM ...
Jul 19 19:16:38 500265-web1 sshd[21188]: Failed publickey for root from ... port ... ssh2
Jul 19 19:16:38 500265-web1 sshd[21189]: ROOT LOGIN REFUSED FROM ...

ルートログインのみに失敗し、セキュリティポリシーでルートログインにキーベース認証のみの使用が許可されている場合、sshd_configファイルの変更が役立ちます。

 PermitRootLogin without-password

あなたの走行距離は変わるかもしれませんが、これはしばしば助けになりますが、いくつかの他の設定はいくつかのsshd_configファイルにあるコメントに従って干渉するかもしれません：

# Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".

この方法でデバッグするためにリモートサーバーの構成を簡単に変更できない場合でも、同じIDファイルを使用して同じリモートサーバー上の非ルートアカウントにsshすることにより、クライアント側の構成をある程度証明できます。

私の場合の理由はAuthorizedKeysFilefileでカスタム設定されたオプションでした/etc/ssh/sshd_config。別のユーザーのホームディレクトリに設定されました（/home/webmaster/.ssh/authorized_keys）ため、ログインしようとしたユーザーはそのファイル/ディレクトリにアクセスできませんでした。

変更してssh-server（service ssh restart）を再起動すると、すべてが正常に戻りました。秘密鍵でログインできるようになりました。

セキュリティがなぜ人を悩ませるのかがわかります。私は持っていたssh won't use my key、再び問題を。リモートサーバーにログインして実行することで解決しました

/usr/sbin/sshd -sDp 23456

そして、デスクトップから（sshからサーバーへ）

ssh -vvvv server -p 23456

サーバー上で Authentication refused: bad ownership or modes for directory /

新しいシステム管理者が許可と所有権を台無しにしていたので、修正しました。

chmod 0755 / ; chown root:root /

（以前は必要chmod 0600 ~/.ssh/* ; chmod 0644 ~/.ssh/*.pubでしたが、sshdによるルート権限の確認/検索は私にとって新しいものです。）今、ルートキットを確認してから、とにかく消去して再インストールします。

私の場合、問題は誤ったシェルexecにありました。

journalctl -f
....
Feb 25 11:45:54 59a02b89e0f6 sshd[]: User user not allowed because shell /usr/bin/env /bin/bash does not exist
....

そのユーザーの/ etc / passwdファイルを変更しました

vi /etc/passwd 
....
user:x:1000:1000::/home/user:/bin/bash
....

私はCentOS 7でこの問題を抱えていました。私は通常のDebianベースのLinuxユーザーですので、私は水から魚でした。一部のサーバーでは機能し、一部のサーバーでは機能しないことに気付きました。audit.logには有用なものは何もなく、secure.logからも何も得られませんでした。唯一の本当の違いは、ファイルとディレクトリのセキュリティコンテキストの違いが、機能するものと機能しないものとの間にあることでした。でセキュリティを確保

sudo ls -laZ <user-home>/.ssh

ディレクトリの（私はsshd_configの多くのデフォルトを仮定しています）。

あなたは、いくつか見るべきであるssh_home_tとuser_home_tの属性を。そうでない場合は、chconコマンドを使用して欠落している属性を追加します。

例えば

home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home".ssh
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"

私の場合、疑わしいのは、ユーザーが非標準的な方法で作成されたということです。彼の家はのディレクトリでした/var/lib。

詳細：https : //www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/

私たちの場合、問題はファイアウォールとNATルールが正しく設定されていなかったという事実に関連していました。

ポート22は、キーとユーザーが認識されていない誤ったサーバーに向けられていました。

誰かがこの点に到達した場合。tcpdumpとtelnetはあなたの友達になることができます

[aaron@aaron-pc ~]$ telnet someserver 22
Trying 1.1.1.1...
Connected to someserver.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.7p1
^]
telnet> 

[aaron@aaron-pc ~]$ telnet someotherserver 22
Trying 1.1.1.2...
Connected to someotherserver.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
^]

これら2つのサーバーには、opensshのバージョンが異なることに気付くでしょう。これにより、問題をかなり迅速に見つけることができました。ホストが同じsshバージョンを使用している場合、宛先でパックされたトレースを実行して、トラフィックが実際に宛先に到着しているかどうかを確認する必要があります。

Sshは大量のトラフィックを生成する可能性があるため、tcpdump出力を探しているものを見つけるのが難しくなります。

これは私を助けました

 tcpdump -i any  "not host [mylocalip] and not localhost and not ip and not arp"

現在のコンピューター@ [mylocalip]ではなく、3つの異なるサーバーからtelnetしてみてください。実際にサーバーに到達するトラフィックを確認したい場合。