SSH를 통해 새 서버에 연결하는 문제를 해결하는 방법에 대한 팁을 찾고 있습니다. SSH가 비밀번호를 묻지 않고 로컬 개인 키를 사용하여 인증하는 개인 키 인증을 사용하여 연결하려고 하는데 문제가 발생했습니다.
을 실행하면 ssh root@newserver
비밀번호를 묻는 메시지가 표시되지 않고 즉시 연결에 성공합니다. 대신 을 실행하면 ssh user@newserver
개인 키 인증 시도가 실패하고 비밀번호를 묻는 메시지가 표시됩니다. 후자가 왜 실패하는지 혼란스러워요. 이것을 디버깅하려면 어떻게 해야 합니까?
내가 시도한 것들:
나는 두 번 확인했고
/root/.ssh/authorized_keys
./home/user/.ssh/authorized_keys
둘 다 동일하며 둘 다 내 공개 키를 포함하고 있습니다.권한
/root/.ssh
과/home/user/.ssh
디렉토리를 다시 확인했습니다newserver
. 모든 것이 괜찮아 보입니다. 어쨌든 권한은 둘 다 동일합니다.두 개의 다른 클라이언트에서 로그인을 시도했는데 두 클라이언트 모두에서 동일한 동작을 보았으므로 이것이 클라이언트에만 국한된 것은 아니라고 생각합니다. 두 클라이언트 모두에서 다른 서버에 성공적으로 로그인할 수 있습니다.
/usr/sbin/sshd -d -p 2323
새 서버에서 실행을 시도 하고ssh -p 2323 root@newserver
및를 사용하여 연결했습니다ssh -p 2323 user@newserver
. 수수께끼 부분은 다음과 같습니다.sshd
명령줄에서 수동으로 실행하면 개인 키 인증을 통해서도 로그인할 수 있지만root
시스템 표준을 사용하려고 하면 개인 키 인증을 통해서만 로그인할 수 있지만 로그인할 수는 없습니다.user
sshd
root
user
나는 도망 갔다
ssh -v
. 나는 깨달음을 얻을 수 있는 어떤 것도 보지 못했습니다: 그것으로ssh -v root@newserver
, 나는 그것을 얻습니다debug1: Offering DSA public key: /home/user/.ssh/id_dsa debug1: Server accepts key: pkalg ssh-dss blen 433
그것으로
ssh -v user@newserver
나는 얻는다debug1: Offering DSA public key: /home/daw/.ssh/id_dsa debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
더 추가해도
-v
통찰력을 얻을 수 없습니다ssh -vvvvv bingen.cs.berkeley.edu
.debug1: Offering DSA public key: /home/daw/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
따라서 개인 키 인증을 통한 로그인 시도가 실패하는 이유에 대한 설명이 없습니다.
Fedora 21, openssh-6.6.1p1-11.1.fc21.x86_64입니다.
답변1
내 생각엔 nlu가 당신에게 올바른 방향을 알려준 것 같아요.
일반적으로 SSH 문제를 추적하는 더 좋은 방법은 sshd
서버 측에서 SSH를 중지한 다음 $(which sshd) -d
.
거의 모든 경우에 이는 보다 의미 있는 오류 메시지를 제공합니다.
업데이트: 죄송합니다. 이미 이 작업을 수행하셨습니다.
cli의 sshd와 서비스의 sshd 사이에는 SELINUX라는 한 가지 차이점이 있는 것 같습니다.
CLI에서는 그다지 엄격하지 않습니다. selinux를 활성화하셨나요? 그렇다면 se-logs/설정을 확인하세요!
답변2
또한 /home/user/.ssh/authorized_keys의 소유권과 권한도 확인해야 합니다.
답변3
알고 보니 SELinux의 파일 권한 문제였습니다 ~/.ssh/
. 외부 드라이브에 저장된 백업에서 파일을 복사했는데 다른 레이블을 받았고 잘못된 레이블이 유지된 것 같습니다.
내가 더 잘 알았어야 했는데. 권한 문제일 수 있는 알 수 없는 오류가 발생하는 경우 항상 SELinux를 확인하세요.
수정사항: restorecon -r /home/user/.ssh
.