SSH 키 인증 실패

Question 1

이는 일반적으로 대부분의 SSH 인증 키 권한 문제를 해결합니다.서버 측에서, 누군가가 권한을 추가로 변경하지 않았다고 가정합니다.

# paste these into an SSH session that server (probably from
# another user account or root)

# change this to YOUR username on the server.
YOURUSER=example

# paste these lines verbatim:
sudo chown $YOURUSER:$YOURUSER /home/$YOURUSER/{.,.ssh/,.ssh/authorized_keys}
sudo chmod u+rwX,go-rwX,-t /home/$YOURUSER/{.ssh/,.ssh/authorized_keys}
sudo chmod go-w /home/$YOURUSER/

(이것이 바로사용자화팀 웹 대시보드의 변경 사항에 따라 권한 문제를 업데이트하고 수정하기 위해 "shim" 스크립트에서 자동으로 수행됩니다.)

관리자가 .ssh/ 디렉터리 또는 .ssh/authorized_keys 파일을 루트로 생성한 경우(이것이 가장 일반적으로 손상됨) 다른 사용자가 파일을 소유하는 것은 허용되지 않습니다.뿌리.

Answer

이는 일반적으로 대부분의 SSH 인증 키 권한 문제를 해결합니다.서버 측에서, 누군가가 권한을 추가로 변경하지 않았다고 가정합니다.

# paste these into an SSH session that server (probably from
# another user account or root)

# change this to YOUR username on the server.
YOURUSER=example

# paste these lines verbatim:
sudo chown $YOURUSER:$YOURUSER /home/$YOURUSER/{.,.ssh/,.ssh/authorized_keys}
sudo chmod u+rwX,go-rwX,-t /home/$YOURUSER/{.ssh/,.ssh/authorized_keys}
sudo chmod go-w /home/$YOURUSER/

(이것이 바로사용자화팀 웹 대시보드의 변경 사항에 따라 권한 문제를 업데이트하고 수정하기 위해 "shim" 스크립트에서 자동으로 수행됩니다.)

관리자가 .ssh/ 디렉터리 또는 .ssh/authorized_keys 파일을 루트로 생성한 경우(이것이 가장 일반적으로 손상됨) 다른 사용자가 파일을 소유하는 것은 허용되지 않습니다.뿌리.

Question 2

Debian Stretch를 실행하는 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 ~/

그런 다음 비밀번호 없이 연결할 수 있었습니다.

Answer

Debian Stretch를 실행하는 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 ~/

그런 다음 비밀번호 없이 연결할 수 있었습니다.

Question 3

CentOS 7을 사용할 때 sshd를 사용하는 다른 Linux OS에도 적용된다고 확신합니다. 루트 액세스를 사용하면 인증이 실패할 수 있는 이유를 자세히 확인할 수 있습니다. 이것을하기 위해:

데몬 에 대한 로깅을 활성화합니다 sshd.sudo vi /etc/ssh/sshd_config
로깅에서 주석 해제:

SyslogFacility AUTH
LogLevel INFO

LogLevel에서 INFO로 변경DEBUG
저장 및 종료
SSH 데몬을 다시 시작하십시오.sudo systemctl restart sshd
메시지 파일 보기tail -l /var/log/messages
다른 터미널을 사용하여 SSH 연결을 시도하십시오.
다음과 연결을 시도합니다.ssh
정확한 원인은 인증 로그를 검토하세요.

예를 들어, 위에서 언급한 것과 동일한 문제를 겪고 있었습니다.

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

이 단계를 사용하여 문제가 파일에 대한 권한인지 확인할 수 있었습니다 authorized_keys. 내 사용자의 chmod 644파일 을 설정하면 authorized_keys문제가 해결되었습니다.

Answer

CentOS 7을 사용할 때 sshd를 사용하는 다른 Linux OS에도 적용된다고 확신합니다. 루트 액세스를 사용하면 인증이 실패할 수 있는 이유를 자세히 확인할 수 있습니다. 이것을하기 위해:

데몬 에 대한 로깅을 활성화합니다 sshd.sudo vi /etc/ssh/sshd_config
로깅에서 주석 해제:

SyslogFacility AUTH
LogLevel INFO

LogLevel에서 INFO로 변경DEBUG
저장 및 종료
SSH 데몬을 다시 시작하십시오.sudo systemctl restart sshd
메시지 파일 보기tail -l /var/log/messages
다른 터미널을 사용하여 SSH 연결을 시도하십시오.
다음과 연결을 시도합니다.ssh
정확한 원인은 인증 로그를 검토하세요.

예를 들어, 위에서 언급한 것과 동일한 문제를 겪고 있었습니다.

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

이 단계를 사용하여 문제가 파일에 대한 권한인지 확인할 수 있었습니다 authorized_keys. 내 사용자의 chmod 644파일 을 설정하면 authorized_keys문제가 해결되었습니다.

Question 4

내가 했어비슷한 문제, 여기서 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.

Answer