서버 비밀번호를 입력하지 않고 자동 SSH 로그인을 설정했습니다.
cd ~/.ssh
ssh-keygen
ssh-copy-id -i ~/.ssh/id_rsa.pub tim@server1
서버에서 실행됩니다.
나중에 다른 서버에서 같은 일을 했습니다.
ssh-copy-id -i ~/.ssh/id_rsa.pub tim@server2
즉시 발생 ssh tim@server2하지만 여전히 비밀번호가 필요합니다. 내가 뭐 잘못 했어요? 두 번째 서버에서 성공적으로 설정하지 못하는 이유는 무엇입니까? (두 번째 서버는 kerberos와 Andrew 파일 시스템을 실행합니다.)
$ ssh -v tim@server2
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to server2 [...] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: identity file /home/tim/.ssh/id_dsa type -1
debug1: identity file /home/tim/.ssh/id_dsa-cert type -1
debug1: identity file /home/tim/.ssh/id_ecdsa type -1
debug1: identity file /home/tim/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/tim/.ssh/id_ed25519 type -1
debug1: identity file /home/tim/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
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<3072<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: Server host key: RSA xxx
debug1: Host 'server2' is known and matches the RSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:70
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
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
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
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Trying private key: /home/tim/.ssh/id_dsa
debug1: Trying private key: /home/tim/.ssh/id_ecdsa
debug1: Trying private key: /home/tim/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
Password:
Diffie-Hellman 키를 사용하는 Anthon의 방법을 시도했지만 여전히 비밀번호를 묻는 메시지가 표시됩니다.
$ cd ~/.ssh
$ ssh-keygen -t dsa
$ ssh-copy-id -i ~/.ssh/id_dsa.pub tim@server2
$ ssh -v tim@server2
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to server2 [...] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: identity file /home/tim/.ssh/id_dsa type 2
debug1: identity file /home/tim/.ssh/id_dsa-cert type -1
debug1: identity file /home/tim/.ssh/id_ecdsa type -1
debug1: identity file /home/tim/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/tim/.ssh/id_ed25519 type -1
debug1: identity file /home/tim/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
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<3072<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: Server host key: RSA ...
debug1: Host 'server2' is known and matches the RSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:70
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
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
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
debug1: Next authentication method: publickey
debug1: Offering DSA public key: /home/tim/.ssh/id_dsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Trying private key: /home/tim/.ssh/id_ecdsa
debug1: Trying private key: /home/tim/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
Password:
답변1
두 번째 서버가 AFS(Andrew File System)를 사용하고 있다고 언급하셨습니다.
아직 사용해본 적은 없지만 AFS는 Kerberos로 보호되는 파일 시스템이며 작동하려면 Kerberos 티켓이 필요하다는 것을 알고 있습니다. 이는 홈 디렉터리에 액세스하려면 사이트의 Kerberos 영역에 로그인해야 함을 의미합니다.
로그인에 비밀번호를 사용하는 경우 server2PAM을 통해 Kerberos 영역에 로그인하도록 설정되었을 수 있습니다. 그러나 SSH 키를 사용하는 경우 server2이를 수행하는 데 필요한 정보를 얻을 수 없으며 홈 디렉터리에 액세스할 수 없습니다.
다행히 ssh -v귀하의 질문 결과를 통해 귀하의 서버에 GSSAPI인증이 활성화되어 있음을 추론할 수 있습니다. 해당 영역에 유효한 Kerberos 티켓이 있는 경우 이를 통해 비밀번호 없는 로그인을 수행할 수 있습니다. 다음을 수행하십시오.
로그인
server2하고klist프로그램을 실행해 보세요. 그러면 다음과 같은 내용이 반환됩니다.Ticket cache: FILE:/tmp/krb5cc_2000 Default principal: [email protected] Valid starting Expires Service principal 28-05-15 15:01:31 29-05-15 01:01:31 krbtgt/[email protected] renew until 29-05-15 15:01:28 28-05-15 15:02:04 29-05-15 01:01:31 IMAP/[email protected] renew until 29-05-15 15:01:28로 시작하는 줄을 찾습니다
Default principal:. Kerberos 주체가 무엇인지 알려줍니다(위 예에서는[email protected]). 이것을 적어보세요. 이는 이메일 주소가 아니며 대소문자를 구분합니다. 즉, 본문은 로 끝나지EXAMPLE.ORG않습니다example.org.- 클라이언트 컴퓨터에서
kinit주체 이름(예: 위의 예에서는 이 이름)으로 실행합니다. 모든 것이 순조롭게 진행되었다면 지금 다시 실행하면 로컬 컴퓨터에 티켓 캐시가 있는 것을 볼 수 있습니다.kinit [email protected]klist - 지금 실행하면
ssh -K server2로그인이 가능하고 시스템에서 비밀번호를 묻지 않아야 합니다.
Kerberos 작동 방식으로 인해 티켓 캐싱의 효과는 제한적입니다. 영역 관리자가 구성한 유효 기간(보통 약 10시간 정도)보다 긴 유효 기간을 가진 티켓 캐시는 요청할 수 없습니다. 티켓이 만료되면 kinit다시 실행하고 비밀번호를 다시 입력 해야 합니다 .
답변2
다음 명령을 사용하여 server2에 연결을 시도해야 합니다.
ssh -v tim@server2
동일한 서버와 비교하면 이 서버에 연결하면 server1두 서버가 얼마나 다른지 정확히 알 수 있습니다.
/etc/ssh/sshd_config두 컴퓨터에는 차이가 있을 가능성이 높습니다. 접근성 문제가 있는 곳 server2이나 장소 ~/.ssh(충분히 제한적이지 않음)
출력 에서 -v확인을 위해 RSA 개인 키를 제공했음을 알 수 있지만 Diffie-Hellman만 지원하는 /home/tim/.ssh/id_rsa것처럼 보입니다 server2(시도가 /home/tim/.ssh/id_dsa존재하지 않을 수도 있음).
답변3
SSH를 시도하려는 클라이언트 컴퓨터에 다음 항목을 추가하십시오.
구성 파일:/etc/ssh/ssh_config
GSSAPIAuthentication no
그러면 해당 머신에 SSH로 접속할 수 있습니다.
파일에 대한 편집 권한이 없으면 추가할 수도 있습니다.
Host *
GSSAPIAuthentication no
~/.ssh/config(파일이 없으면 생성 )
답변4
매우 비슷한 문제가 있었고 해결했습니다.
계속해서 비밀번호를 사용하여 로그인하면 여전히 추가 경고가 표시됩니다.
Remote: Ignored authorized keys: bad ownership or modes for directory /home/myusername/.ssh
일반적인 실수는 클라이언트와 서버 모두에서 올바른 권한으로 변경하는 것을 잊어버리는 것입니다.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_key
gssapi와 관련된 모든 것은 붉은 청어입니다.
근본 원인은 공개 키를 사용하여 연결을 시도할 때 문제가 발생했습니다.
공개 키->gssapi-keyex, gssapi-with-mic->password
디버그 파일은 SSH 버전이 다르기 때문에 내 파일과 다르게 보이지만 다음 줄을 살펴보세요.
debug1: Roaming not allowed by server
먼저 폴더와 파일에 대한 권한을 확인하려고 합니다.