私はこの問題に対する多くの解決策を読んだが、私が見ているものとは何も効果がないようです。ほとんどはディレクトリ権限に焦点を当てていますが、この場合はこれが正しいようです。重要な要約：同じホームディレクトリを持つ2つのCentos7サーバー。sshd有効にしても公開鍵認証は許可されません。
2つのcentos7サーバーがあります。centos-aこれを。centos-bホームディレクトリはNFSを介してマウントされるため、.ssh2つの間のディレクトリは同じです（下記を参照してください）。centos-aからSSH経由で接続できますが、centos-asshで接続できませんcentos-b。からSSH経由でcentos-b移動できます。centos-acentos-b
| SSH機能 | centos-a |
centos-b |
|---|---|---|
centos-a |
はい | いいえ |
centos-b |
はい | はい |
[myuser@centos-a ~]$ ls -la ~/.ssh
total 16
drwx------. 1 myuser domain users 0 Jul 6 11:45 .
drwx------. 1 myuser domain users 0 Jul 7 13:44 ..
-rw-------. 1 myuser domain users 1212 Jul 6 12:02 authorized_keys
-rw-------. 1 myuser domain users 1675 Jul 6 11:45 id_rsa
-rw-r--r--. 1 myuser domain users 402 Jul 6 11:45 id_rsa.pub
-rw-r--r--. 1 myuser domain users 1119 Jul 6 17:49 known_hosts
[myuser@centos-a ~]$ md5sum ~/.ssh/*
65b4fdf2d59cee3ae45b8480454453ec /home/myuser/.ssh/authorized_keys
fa3e9fc5a8ff08787ff2ba8f979da24e /home/myuser/.ssh/id_rsa
dca36ab3ec342423c5eca588f2ad5678 /home/myuser/.ssh/id_rsa.pub
f67bc94bc7a30b9876e3027b24f893d8 /home/myuser/.ssh/known_hosts
[myuser@centos-a ~]$ ssh centos-a hostname
centos-a
[myuser@centos-a ~]$ ssh centos-b hostname
myuser@centos-b's password:
[myuser@centos-b ~]$ ls -la ~/.ssh
total 16
drwx------. 1 myser domain users 0 Jul 6 11:45 .
drwx------. 1 myser domain users 0 Jul 7 13:44 ..
-rw-------. 1 myser domain users 1212 Jul 6 12:02 authorized_keys
-rw-------. 1 myser domain users 1675 Jul 6 11:45 id_rsa
-rw-r--r--. 1 myser domain users 402 Jul 6 11:45 id_rsa.pub
-rw-r--r--. 1 myser domain users 1119 Jul 6 17:49 known_hosts
[myuser@centos-b ~]$ md5sum ~/.ssh/*
65b4fdf2d59cee3ae45b8480454453ec /home/myuser/.ssh/authorized_keys
fa3e9fc5a8ff08787ff2ba8f979da24e /home/myuser/.ssh/id_rsa
dca36ab3ec342423c5eca588f2ad5678 /home/myuser/.ssh/id_rsa.pub
f67bc94bc7a30b9876e3027b24f893d8 /home/myuser/.ssh/known_hosts
[myuser@centos-b ~]$ ssh centos-b hostname
centos-b
[myuser@centos-b ~]$ ssh centos-a hostname
centos-a
上記のように、.sshディレクトリに対する権限は正しいようです（とにかく2つのシステム間で同じです）。
ssh -vvv失敗した SSH は以下を表示します。
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
...
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
...
debug1: Host 'centos-b' is known and matches the ECDSA host key.
...
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,password
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password
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,password
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 (default cache: KEYRING:persistent:1211402155)
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1211402155)
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/myuser/.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: Trying private key: /home/myuser/.ssh/id_dsa
debug3: no such identity: /home/myuser/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/myuser/.ssh/id_ecdsa
debug3: no such identity: /home/myuser/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/myuser/.ssh/id_ed25519
debug3: no such identity: /home/myuser/.ssh/id_ed25519: No such file or directory
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
myuser@centos-b's password:
これをで見たものと対照すると、次のようにcentos-b動作centos-aします。
...
debug1: Unspecified GSS failure. Minor code may provide more information
Server not found in Kerberos database
debug3: send packet: type 50
debug2: we sent a gssapi-with-mic 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
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/myuser/.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 60
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug2: input_userauth_pk_ok: fp SHA256:nAO5pVOzqUQzEUSEBN37WKp6ADs9Sk4rfTRGmk0FHEY
debug3: sign_and_send_pubkey: RSA SHA256:nAO5pVOzqUQzEUSEBN37WKp6ADs9Sk4rfTRGmk0FHEY
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
SSHDログメッセージを有効にし/etc/ssh/sshd_configてサービスを再起動しました。
# Logging
SyslogFacility AUTH
SyslogFacility AUTHPRIV
LogLevel INFO
/var/log/secureしかし、どちらにも他の有用なニュースはありません/var/log/messages。
楽しくcentos-bSSHでcentos-bgssapi認証を使用します。公開鍵の使用を強制すると失敗します。
[myuser@centos-b ~]$ ssh -vvv -o PreferredAuthentications=publickey centos-b hostname
...
debug1: Offering RSA public key: /home/myuser/.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
...
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
私は見た/var/log/messages：
Jul 7 13:52:10 centos-b sshd[23266]: Connection closed by 192.168.1.100 port 48064 [preauth]
公開鍵が有効になっている：
[root@centos-b ssh]# sshd -T | grep -i pub
pubkeyauthentication yes
pubkeyacceptedkeytypes [email protected],ecdsa-sha...
これはsshd_config在庫Centos7でありsshd_config、間で同じです（両方のシステムで次のコマンドをパイピングして確認）。centos-acentos-bmd5sum
[root@centos-b ssh]# grep -v -e '^#' -e '^$' /etc/ssh/sshd_config
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
SyslogFacility AUTHPRIV
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication yes
ChallengeResponseAuthentication no
GSSAPIAuthentication yes
GSSAPICleanupCredentials no
UsePAM yes
X11Forwarding yes
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
Subsystem sftp /usr/libexec/openssh/sftp-server
私が逃したことについての提案はありますか？
答え1
.ssh問題は、IDディレクトリ（おそらくそれ以上）のSELinuxコンテキストに関連している可能性があります。コンテキスト（in .ssh）にタイプがあることを確認してくださいssh_home_t。
これはSSHユーザーファイルに必要な権限に似ています（rwxグループ/その他には必要ありません）。確認しませんでしたが、おそらく両端に必要です（.sshソースとターゲットのユーザーディレクトリの両方が同じコンテキストを必要とします）。
以下は、「正しい」コンテキストの例です。
[account@hostname .ssh]# ls -alZ
drwx------. account account unconfined_u:object_r:ssh_home_t:s0 .
drwx------. account account unconfined_u:object_r:user_home_dir_t:s0 ..
-rw-------. account account unconfined_u:object_r:ssh_home_t:s0 authorized_keys
-rw-------. account account unconfined_u:object_r:ssh_home_t:s0 id_rsa
-rw-------. account account unconfined_u:object_r:ssh_home_t:s0 id_rsa.pub
-rw-r--r--. account account unconfined_u:object_r:ssh_home_t:s0 known_hosts
答え2
追加のインターネット検索では、私が設定した新しいシステムでSELinuxを有効にするのに問題があると述べました。私の場合、許可に設定すると問題が解決しました。
# getenforce
Enforcing
# setenforce 0
# getenforce
Permissive
これは、自分の環境にSELinuxが必要な人にとっては適切なソリューションではないかもしれません。永続的な変更には更新が含まれます/etc/selinux/config。
答え3
さて、私は新しく作成したDebian 12サーバーで同じことをして、この問題を解決するのに5時間を費やしました。
- .ssh ファイル/フォルダに対する権限の確認
- /etc/ssh/sshd_config ファイルをジョブホストと比較する
sshd -T出力をジョブ・ホストと比較- 出力比較
ssh -vvv root@host 2>ssh.log - オンライン調査が多い
その結果、この特定のホストでなぜこれが起こるのかはまだわかりません。毎月何十ものVMでこれを行いますが、そうすることで、scp-copy-id root@hostデフォルト以外の目的に使用する代替公開鍵がインストールされます。思ったところ~/.ssh/id_rsa.pub。
したがって、ここに来たがまだ完了していない場合は、ターゲットの~/.ssh/authorized_keysをクライアントの~/.ssh/id_rsa.pubと比較してください.
同じでない場合は、ターゲットホストのAuthorized_keysから無効なエントリを削除してから（またはファイルが1つしかない場合はファイルを削除）、明示的にインポートする必要があります。
ssh-copy-id -i ~/.ssh/id_rsa.pub root@host
私のビルドルーチンを修正しました。