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 파일을 루트 (가장 일반적으로 수행되는 방법)로 생성 한 경우 (루트 인 경우에도) 다른 사용자가 파일을 소유하는 것은 허용되지 않습니다.

Userify (면책 조항 : 공동 창업자)는 자동으로 동일한 방식으로 자동 수행합니다. https://github.com/userify/shim/blob/master/shim.py#L285

나는 데비안 스트레치 (Debian stretch)를 실행하는 리눅스와 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

따라서 보안에 신경 쓰지 않는 개발자 VM 용 솔루션은 selinux를 비활성화합니다. / etc / sysconfig / selinux를 편집하고 SELINUX = disabled를 변경하고 재부팅하십시오.

만일 누군가를 구하기 위해서도 마찬가지입니다. 우분투 18.04 머신에서 2 CentOS 7 서버로 키를 복사하려고했습니다. 나는 ssh-copy-id그들을 옮겼었다. 하나는 작동했지만 하나는 작동하지 않았습니다. 그래서 모든 권한 디버깅을 수행했지만 아무것도 찾지 못했습니다. 마지막 /etc/ssh/sshd_config으로 두 서버 에서 파일 을 가져 와서 한 줄씩 단계별로 실행했습니다. 마지막으로, 나는 아마도 내가 일을 시작하기 오래 전에 누군가가 수정 한 것을 발견했습니다.

한 번 읽음 : AuthorizedKeysFile .ssh/authorized_keys

그리고 또 다른 읽기 : AuthorizedKeysFile ~/.ssh/authorized_keys서버에서 내 키를 수락하지 않은 것입니다. 분명히 두 파일 사이를 살펴보고 기본 검색 패턴에 주석이 포함되어 있다는 주석은 주목하고 주석을 ~/제거하고 다시 시작했습니다. 문제 해결됨.

이 문제도 발생했습니다. setroubleshoot가 내 환경에서 작동하지 않는 것 같으므로 / var / log / messages에 이러한 로그 레코드가 없었습니다. SELinux를 비활성화하는 것은 나에게 옵션이 아니기 때문에

restorecon -Rv ~/.ssh

그 후 rsa 키로 로그인하면 정상적으로 작동했습니다.

필자의 이유는 AuthorizedKeysFilefile에서 사용자 정의 옵션 을 설정했기 때문입니다 /etc/ssh/sshd_config. 다른 사용자의 홈 디렉토리 ( /home/webmaster/.ssh/authorized_keys) 로 설정되어 있으므로 로그인하려는 사용자가 해당 파일 / 디렉토리에 액세스 할 수 없었습니다.

그것을 변경하고 ssh-server ( service ssh restart)를 다시 시작하면 모든 것이 정상으로 돌아 왔습니다. 개인 키로 로그인 할 수 있습니다.

우리의 경우 문제는 방화벽 및 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 out이 원하는 것을 찾기가 어려워집니다.

이것은 나를 도왔다

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

현재 컴퓨터 @ [mylocalip]가 아닌 3 개의 다른 서버에서 텔넷을 시도하십시오. 실제로 어떤 트래픽이 서버에 도달하는지 확인하려고합니다.

다음과 같이 끝나는 클라이언트 측 오류 로그 :

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 하여 클라이언트 측 구성을 어느 정도 증명할 수 있습니다 .

보안이 사람들을 괴롭히는 이유를 알 수 있습니다. 방금 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 /

일부 새로운 sysadmin은 권한과 소유권을 엉망으로 만들었습니다.

chmod 0755 / ; chown root:root /

(필자는 익숙 chmod 0600 ~/.ssh/* ; chmod 0644 ~/.ssh/*.pub하지만 sshd 루트 권한을 확인 / 찾기하는 것은 새로운 것입니다.) 이제 루트킷을 확인한 다음 어쨌든 닦아서 다시 설치하겠습니다.

제 경우에는 잘못된 셸 실행 문제가 발생했습니다.

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에서이 문제가 발생했습니다. 나는 데비안 기반의 일반 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/