SSH 연결 문제 해결

SSH 연결 문제 해결

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시스템 표준을 사용하려고 하면 개인 키 인증을 통해서만 로그인할 수 있지만 로그인할 수는 없습니다.usersshdrootuser

  • 나는 도망 갔다 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.

관련 정보