web-dev-qa-db-ja.com

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 [email protected]
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: [email protected],[email protected],[email protected],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: [email protected],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: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: [email protected],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,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: [email protected]
debug1: kex: Host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] 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).
sshsshdssh-keys
20
Tim

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

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

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

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

13
Jamieson Becker

私は2つのサーバー上で全く同じ問題を抱えていました：Debianストレッチを走らせているLinuxとNAS（Synology DS715）

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

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

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

linuxでは、write/groupビットがオン（drwxrwxr - x）なので、少なくともグループへの書き込み（chmod g-w〜/）を削除する必要がありました。

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

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

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

chmod -t ~/

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

11
Cyril Chaboisseau

CentOS 7を使用しているとき、私はsshdを使用している他のLinux OSにも適用できると確信しています。 rootアクセスを使用すると、認証が失敗する可能性がある理由についてさらに詳しく判断できます。これをする：

  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に設定することによって、問題は修正されました。

3
JonCav

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

厳密モードが有効になっている場合は、.sshに正しいパーミッションがあることを確認する必要があります。

  • .ssh/はpermを持つべきです0700/rwx------
  • .ssh/*.pubファイルは644/rw-r--r--であるべきです
  • .ssh/*（.ssh内の他のファイル）0600/rw-------

パーミッション的に物事はどのようにあなたのために見えますか？

3
Kyle H

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

2
Nathan Crause

私は 同様の問題 を抱えていました。そこでは、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 .

1
Elouan Keryell-Even

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

restorecon -Rv ~/.ssh

Rsaキーによるそのログインの後はうまくいきました。

1
lapin_

念のために、これも誰かを救います。私の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を再起動しました。問題が解決しました。

1
Aaron Chamberlain

この問題に遭遇しました。 .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

だから、セキュリティを気にしない開発者vmのための解決策は、selinuxを無効にすることです。/etc/sysconfig/selinuxを編集し、SELINUX = disabledを変更して再起動します。

1
gaoithe

クライアントサイドのエラーログは次のようになります。

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
[email protected]'s password:

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

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 ...

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

 PermitRootLogin without-password

あなたの走行距離は変わるかもしれませんが、これはしばしば助けになりますが、いくつかのsshd_configファイルに見いだされるコメントによると、他の設定がまだ妨害するかもしれません：

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

この方法でデバッグするようにリモートサーバーの設定を簡単に変更できない場合でも、同じ識別ファイルをsshに設定することである程度クライアント側の設定を証明することができます。同じリモートサーバー上の-rootアカウント。

0
kbulgrien

私たちの場合、問題は私たちのファイアウォールと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
^]

あなたはこれら二つのサーバが異なるopensshバージョンを持っていることに気付くでしょう。これは私が問題をすぐに見つけるのを助けました。あなたのホストが同じsshバージョンを使っているなら、あなたはトラフィックが実際に目的地に到着しているかどうか見るために目的地でパックされたトレースをしてみる必要があるでしょう。

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

これは私を助けました

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

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

0
nelaaro

なぜセキュリティが人々を悩ませているのかがわかります。もう一度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によるroot権限の確認/検索は私にとっては新しいものです。）今度はrootkitを確認し、それから拭いて再インストールします。

0
Alexx Roche

私は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/

0
hanzo2001

私の場合、問題は不正なShell 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
....
0
nelaaro

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

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

0
ihoru