원격 컴퓨터에 SSH로 로그인하려고하지만 여전히 암호를 요구합니다

원격 컴퓨터에 SSH로 접속하려고하지만 여전히 암호를 요구합니다.

SElinux를 실행하는 여러 컴퓨터가 있는데 그 중 하나만이 암호없이 ssh를 사용하는 데 어려움을 겪고 있습니다.

ssh-copy-id를했는데 .ssh / authorized_keys에서 내 키를 볼 수 있습니다.

chmod 700 .ssh 및 chmod 600 ./ssh/*의 모든 파일

ssh -v를 수행하면 이것이 내 출력입니다.

OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to wcmisdlin05 [10.52.208.224] port 22.
debug1: Connection established.
debug1: identity file /home/jsmith/.ssh/identity type -1
debug1: identity file /home/jsmith/.ssh/id_rsa type 1
debug1: identity file /home/jsmith/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'wcmisdlin05' is known and matches the RSA host key.
debug1: Found key in /home/jsmith/.ssh/known_hosts:9
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_501' not found

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_501' not found

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


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


debug1: Next authentication method: publickey
debug1: Offering public key: /home/jsmith/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/jsmith/.ssh/identity
debug1: Trying private key: /home/jsmith/.ssh/id_dsa
debug1: Next authentication method: password

누군가이 원격 컴퓨터에서 왜 작동하지 않는지 알려주시겠습니까?

나는 종종 SEOS 와 관련된 CentOS 6 머신에서 비슷한 버그 가 발생했습니다 ssh-copy-id.

ssh-copy-id권한이 부여 된 키 파일을 작성할 때 올바른 권한이 있지만 SELinux 레이블이 잘못된 파일이 작성됩니다. 이 문제를 해결하려면 다음 명령을 사용하여 레이블을 정책 기본값으로 복원하십시오.

restorecon -R ~/.ssh

가능하면 서버 측에서 이러한 것들을 훨씬 쉽게 디버깅 할 수 있습니다. 디버그 모드에서 다른 포트에서 sshd를 시작할 수 있다면 키가 거부되는 이유를 즉시 알 수 있습니다 (홈 디렉토리는 그룹 쓰기 가능하다는 것이 추측입니다). 예를 들어을 사용하여 포트 2222에서 디버그 모드로 sshd를 시작한 /usr/sbin/sshd -d -p 2222다음로 연결할 수 있습니다 ssh -p 2222 user@remotehost.

SElinux를 언급 한 포스터가 내 문제로 머리를 깎았습니다. selinux를 사용하고 싶지 않지만 그것을 비활성화하는 것을 잊어 버렸고 서버는 부팅시 selinux를 활성화했습니다.

ssh -v디버그 도움이되었습니다. 열쇠는 받아 들여진다 :

debug1: Found key in /var/lib/amanda/.ssh/known_hosts:19
debug1: ssh_rsa_verify: signature correct

그런 다음 오류가 발생합니다

debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_502' not found

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_502' not found

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


debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_502' not found

내 수정은 selinux를 끄고 setenforce 0/ etc / selinux에서 비활성화하는 것이 었습니다 . 그런 다음 ssh passwordless login이 나를 위해 일했습니다.

나는 RHEL5에서 언젠가 이것을 경험했고 (이것이 당신이 사용하는 배포판인지 알지 못합니다) ssh-copy-id를 사용할 때만 발견되었습니다. 키 파일을 올바른 폴더로 스캔하고 권한을 재설정하십시오.

제 경우에는 문제가 authorized_keys파일 형식이 잘못되었습니다 .

이 없어야 더 줄 바꿈 형식 정의 (사이 ssh-rss, ssh-dss..)와 공개 키 자체.

나는 ssh와 keyfiles에 문제가 있었다. 그때 내 ID 키의 이름을 " id_rsa"(으)로 바꾸는 데 도움이되었습니다. 불행히도 서버마다 다른 키가 있습니다. 따라서이 방법은 유용성이 제한되어 있습니다. 일회성으로 도움이 될 수 있습니다.

두 번째로 오늘 나는 하나의 XTerm 세션에서만이 오류가 발생했으며 6 개의 다른 xterm 세션에서 동일한 서버 / 호스 시스템으로 모든 것이 잘 작동합니다. 그래서 env두 세션 에서 얻은 결과를 비교 했습니다. 이것이 작동하지 않는 세션에는 없었던 작동중인 세션이라는 것을 알았습니다.

SSH_AUTH_SOCK=/run/user/1001/keyring/ssh 

해당 과제를 휴무 세션에 붙여 넣었습니다.

export SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
ssh  user@host
... Welcome ...

다시 말해 그 솔루션은 저에게 효과적이었습니다.

SSH_AUTH_SOCKET을 약간 확인했습니다. 이 답변에서 :

• ssh-agent는 SSH_AUTH_SOCK를 어떻게 설정하고 사용합니까?

에이전트가 다른 프로세스와의 통신에 사용하는 유닉스 파일 소켓의 경로

나는 이것이 결과를 기반으로 한 키 해상도에 필수적이라고 생각합니다.

debug1 : 공개 키 제공 : /home/jsmith/.ssh/id_ rsa

...

debug1 : 개인 키 시도 : /home/jsmith/.ssh/id_ dsa

개인 / 공개 키가 일치하지 않는 것 같습니다. 키 이름은 공개 키가 RSA 키이고 개인 키가 DSA임을 나타냅니다.

scp서버에 새 쌍과 공개 키 를 생성하십시오 .

./ssh 및 사용자의 홈 디렉토리, 키 파일 및 authorized_keys 파일에 대한 권한을 확인하는 것이 좋습니다. ssh 암호가없는 연결이 작동하려면 소유자가 거기에서 읽고 쓸 수 있어야합니다. 그것은 소스 머신과 타겟 머신 모두에 관한 것입니다. 솔직히 말하면 때로는 더 큰 권리가 있어도 작동하지만 그렇지는 않습니다.