호스트가 SSH 키를 허용했지만 클라이언트 연결 끊기

헬리콥터,

fedora 23 설치 후 SSH에 문제가 있습니다.

개인 키로 원격 호스트에 연결하지 않으려는 경우 내 호스트는 키를 찾습니다.

debug1: matching key found: file /home/theo/.ssh/authorized_keys, line 1 RSA {REDACTED}
debug1: restore_uid: 0/0
Postponed publickey for theo from {REDACTED} port 60351 ssh2 [preauth]
Connection closed by {REDACTED} [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed

하지만 내 고객이 스스로 연결을 끊는 것을 보면

debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tbouge/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

동일한 개인 키를 사용하여 Windows에서 퍼티로 호스트에 연결할 수 있으며 다른 개인 키를 사용하여 내 전화에 연결할 수 있습니다.

당신은 어떤 아이디어가 있습니까?

/ etc / ssh / ssh_conf

Host *
        GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
        ForwardX11Trusted yes
# Send locale-related environment variables
        SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
        SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
        SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
        SendEnv XMODIFIERS

감사합니다

편집 : 비밀번호로 연결할 수 있습니다

우선, 공개 키 기반 인증을 설정 또는 구성하는 방법에 대한 매우 잘 작성된 자세한 문서 가 온라인으로 제공됩니다. 그중 하나를보고 모든 것을 올바르게 준수했는지 확인하십시오. 여기 하나입니다. 다시 반복하지 않겠습니다.

가장 기본적인 개념은 ( 여기 에서 복사 ) :

키 기반 인증은 누구나 볼 수있는 "공개"키와 소유자 만 볼 수있는 "개인"키의 두 가지 키를 사용합니다. 키 기반 인증을 사용하여 안전하게 통신하려면 키 페어를 생성하고, 로그인하려는 컴퓨터에 개인 키를 안전하게 저장하고, 로그인하려는 컴퓨터에 공개 키를 저장해야합니다.

이제 디버그 로그에서 게시했습니다.

• 두 가지 다른 사용자가 관련되어있는 것 같습니다. /home/theo/.ssh/authorized_keys그리고 /home/tbouge/.ssh/id_rsa. 한 사용자로 다른 사용자의 홈 디렉토리에 로그인하려고합니까?
• 이 오류 Postponed publickey for theo..는 공개 키 방법 전에 원하지 않는 인증 방법을 시도했음을 의미합니다. SSH는 구성에서 활성화 된 모든 인증 방법을 차례로 시도합니다. 귀하의 경우 GSSAPIAuthentication yes사용하지 않는 것을 활성화했습니다. 를 수행하여 안전하게 비활성화 할 수 있습니다 GSSAPIAuthentication no.
• debug2: we did not send a packet, disable method개인 키 파일을 처리 할 수 ​​없습니다 (파일 권한 또는 이름 문제). SSH는 로컬 및 원격 컴퓨터의 디렉토리 및 파일 권한에 매우 민감합니다. ( chown user_name:user_group -R /home/user, chmod 700 /home/.ssh, chmod 600 /home/.ssh/authorized_keys). 따라서 올바르게 설정되어 있는지 확인하십시오. 이것을보십시오 : /unix/131886/ssh-public-key-wont-send-to-server

• 세 번째 오류 : Permission denied (public key).확인해야 할 몇 가지가 있습니다.

  • 잘못된 사용자 이름
  • 잘못된 키 페어

  • 잘못된 대상 호스트

    • 자세한 내용은 /programming/18551556/permission-denied-publickey-when-ssh-access-to-amazon-ec2-instance 입니다.

다음 부분은 약간 혼동됩니다.

debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method

더 잘 이해하려면 다음과 같이 digitalocean에 설명 된대로 인증 프로세스를 단계별로 진행하십시오 .

1. 클라이언트는 인증하려는 키 페어의 ID를 서버에 전송하여 시작합니다.
2. 서버가 클라이언트가 키 ID에 로그인하려고하는 계정의 authorized_keys 파일을 검사합니다.
3. 일치하는 ID를 가진 공개 키가 파일에 있으면 서버는 난수를 생성하고 공개 키를 사용하여 번호를 암호화합니다.
4. 서버는 클라이언트에게이 암호화 된 메시지를 보냅니다.
5. 클라이언트에 실제로 연결된 개인 키가있는 경우 해당 키를 사용하여 메시지의 암호를 해독하여 원래 번호를 표시 할 수 있습니다.
6. 클라이언트는 해독 된 숫자를 통신 암호화에 사용되는 공유 세션 키와 결합하고이 값의 MD5 해시를 계산합니다.
7. 그런 다음 클라이언트는이 MD5 해시를 암호화 된 숫자 메시지에 대한 응답으로 서버로 다시 보냅니다.
8. 서버는 동일한 공유 세션 키와 클라이언트로 보낸 원래 번호를 사용하여 자체적으로 MD5 값을 계산합니다. 자체 계산을 클라이언트가 다시 보낸 계산과 비교합니다. 이 두 값이 일치하면 클라이언트가 개인 키를 소유하고 있고 클라이언트가 인증되었음을 나타냅니다.

귀하의 경우, 알 수 있듯이 원격 컴퓨터는을 수락 public key하고 해당 키로 패킷을 암호화하여 클라이언트 컴퓨터로 다시 보냈습니다. 이제 클라이언트 컴퓨터는 자신의 권리가 있음을 증명해야합니다 private key. 올바른 private_key 만 있으면 수신 된 메시지를 해독하고 응답을 보낼 수 있습니다. 이 경우 클라이언트가이를 수행하지 못하고 인증 프로세스가 성공하지 않고 종료됩니다.

이것이 문제를 이해하고 해결하는 데 도움이되기를 바랍니다.

ssh 파일에 대한 권한이 정확합니까?

.ssh 폴더-> 700

공개 키-> 644

개인 키-> 600

또한 사용자 및 그룹 확인

Windows 시스템에서 동일한 키를 가지고 있다고 말합니다. Linux 시스템에있는 개인 키 파일이 올바른지 확인하십시오. 개인 키가 ssh가 쉽게 이해하지 못하는 퍼티 형식 일 수 있습니다. 어쨌든, 잘못되었거나 유효하지 않은 개인 키 파일을 넣으면 정확히 같은 오류가 발생합니다.

문제를 해결하려면 다른 시스템의 키를 재사용하는 대신 Linux 시스템에서 새 키를 생성하는 것이 더 적절합니다. 새 공개 키를 호스트의 authorized_keys 파일에 추가하면 Windows의 Windows 키와 Fedora의 새 Linux 키를 모두 사용할 수 있습니다.

당신의 문제는 꽤 일반적이며 내가 말한 것 같습니다.

 Permission denied (publickey).

그게 당신에게 어떤 의미가 있습니까? 나에게 그것은 많은 의미가 있습니다.

강제 모드 pls에서 selinux runnin이 있는지 서버 측에서 확인할 수 있습니까? 그렇지 않다면 selinux가 어떤 모드에서 실행 중인지 알려주십시오.

또한 한 번 더 시도하고 해당 시도의 감사 로그를 캡처하고 여기에 게시하면 이유를 알 수 있습니다.

  tail -f /var/log/audit/audit.log  (and try to attempt)

명확하지만 파일 권한이 아닌 권한 문제입니다.

문제는 (내 경우에는 ...) 키 유형으로 인한 것 같습니다.

방금 로컬 ~/.ssh/config파일 (Fedora 23 클라이언트 시스템)에 다음을 추가하여 해결했습니다 .

PubkeyAcceptedKeyTypes=+ssh-dss

서버와 클라이언트 구성 파일 모두에 해당 줄을 추가했지만 클라이언트 쪽에서 만 차이가있었습니다. 600구성 파일을 읽으 려면 권한이 있어야합니다 .

다른 사람이 여전히이 문제를 겪고 있는지 모르겠지만 마침내 문제가 발생한 내 컴퓨터 (노트북)에 대해이 문제를 해결했습니다. 나는 그것이 결국 그것을 분류 한 것을 알고 있다고 생각 하며, 여전히이 문제가 여전히 발생할 수있는 다른 누군가를 도울 것이라는 희망으로 여기에 정보를 남길 것입니다-그리고 누군가가 희망적으로 내 솔루션을 확인하고 그것이 실제로 무엇인지 확인할 수 있도록 문제를 해결했다.

문제는 SSH가 전혀 아니었지만 PAM이 내 키를 구성하는 방식과 관련이 있습니다. 구성 /etc/pam.d이 오래되었습니다 (Fedora 22를 통해 제대로 작동했지만). 로그인에서 더 이상 내 키를 가져 오기 위해 올바른 작업이 수행되지 않았습니다 $HOME/.ssh/. 이 명령을 실행 :

# sudo authconfig --updateall

/etc/pam.d 구성을 올바르게 다시 빌드하십시오. 다음에 다시 부팅 할 때, 로그인 한 후 처음으로 서버에 ssh를 시도 할 때 ssh 키 ( $HOME/.ssh/id_rsa)에 대한 암호를 입력하라는 대화 상자가 표시되었습니다 . "로그인 할 때 자동으로 잠금 해제"상자를 체크하고 짜라! 랩탑에서 나가는 능력이 회복되었습니다.

배경

이 문제를 해결하게 된 단서는 외부 소스에서 RSA 키를 가져올 때 발생했습니다. (내가 다니는 USB 키, 내 홈 네트워크 내 "원격 액세스"키. 나는 전에 침입 후 내 바깥쪽으로 향하는 서버 년 PasswordAuth 끌.) 후 ssh-add-ing THAT RSA 키를, 앉아 사람과는 달리 $HOME/.ssh/id_rsa, 원격 서버가 문제없이 승인했습니다.

그런 다음 중복되어야 할 일을 끝내기 시작 ssh-add했습니다 $HOME/.ssh/id_rsa. 나는 그렇게 한 후에 동일한 키에 대한 두 개의 항목이 ssh-add -l포함되어 있음을 알았습니다 .

% ssh-add -l
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX id_rsa (RSA)
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX me@host (RSA)
2048 SHA256:YYYYYYYYYYYYYYYYYYYYYY imported@usbkey (RSA)

두 항목 중 하나에 키 식별자가 표시되지 않으며 공개 서명과 일치하는 개인 키 파일 이름 만 표시됩니다. 개인 키가 실제로 키 링 관리자에 의해 잠금 해제 되지 않은 것처럼 .

나는 그것이 정확히 일어나고 있다고 믿었고, PAM은 암호문으로 잠금 해제되지 않은 SSH 에이전트에 "잘못된 키"를 전달하고있었습니다. 따라서 ssh가 키로 인증을 시도했을 때 실제로 키 쌍의 (잠금 해제 된) 개인 절반이 없으므로 인증에 실패했습니다.

마지막 비트는 추측이지만 F23으로 업그레이드 한 후 원격 호스트 (예전의 위치)에서 ssh 키를 받아들이지 않는 문제가있는 사람은 /etc/pam.d/디렉토리를 사용하여 authconfig솔루션을 시도하는 것이 좋습니다.

사용자 홈 디렉토리 권한을 확인하십시오. 중요합니다. 755 여야합니다. 700 또는 770이 작동하지 않습니다.

당신의에서 ssh_config, 주석을 해제 및 / 또는 추가 / 제거 /를 하나에 추가하려고 Cipher, Ciphers또는 MACs라인 (들).

sshd요청에 포함되지 않은 일종의 특정 암호를 찾고있는 것으로 보입니다.이 암호는에서 구성하여 추가 할 수 있습니다 ssh_config.

... 원격으로 원격 서버에 PubkeyAuthentication설정 하지 않았다고 가정합니다 no. 이로 인해 실패 할 수 있기 때문입니다.