비밀번호 프롬프트없이 ssh가 정지됨 — 루트 또는 다른 계정에서 작동

ssh 키 기반 로그인이 정상적으로 작동했습니다. 그런 다음 컴퓨터에서 호스트 이름을 변경하고 키 기반 로그인의 작동이 중지되었습니다. 말이되는 것 같았습니다. 키는 아마도 이전 호스트 이름에 의존했을 것입니다. 그래서 ~ / .ssh /의 모든 키와 모든 파일을 삭제하고 다시 생성했습니다 (연결하는 서버에서 authorized_keys를 변경했습니다)

이제 ssh를 시도 할 때마다 키 기반 로그인이 설정되어 있지 않은 서버조차도 ssh하려는 위치에 관계없이 비밀번호 프롬프트없이 중단됩니다. .ssh / config에는 아무것도 없습니다.

또한 루트에 'su-'하면 ssh가 완벽하게 작동합니다. 전혀 문제 없습니다. 이것은 내 사용자 계정에서만 발생합니다.

아래는 ssh의 디버깅 정보입니다.

ssh -vv mylogin@myremoteserver.com
OpenSSH_5.2p1, OpenSSL 0.9.8k 2009 년 3 월 25 일
debug1 : 구성 데이터 읽기 /Users/myname/.ssh/config
debug1 : 구성 데이터 읽기 / usr / etc / ssh_config
......
debug1 : 'myremoteserver.com'호스트가 알려져 있으며 RSA 호스트 키와 일치합니다.
debug1 : /Users/myname/.ssh/known_hosts:1에서 키를 찾았습니다.
debug2 : 비트 세트 : 512/1024
debug1 : ssh_rsa_verify : 서명이 올바른
debug2 : kex_derive_keys
debug2 : set_newkeys : 모드 1
debug1 : SSH2_MSG_NEWKEYS가 전송되었습니다.
debug1 : SSH2_MSG_NEWKEYS 예상
debug2 : set_newkeys : 모드 0
debug1 : SSH2_MSG_NEWKEYS 수신
debug1 : SSH2_MSG_SERVICE_REQUEST가 전송되었습니다.
debug2 : service_accept : ssh-userauth
debug1 : SSH2_MSG_SERVICE_ACCEPT를 받았습니다

그리고 여기에 매달립니다 .....

다음은 정지 지점 근처의 strace와 같은 dtruss 출력입니다. sudo dtruss ssh -vv mylogin@myremoteserver.com

선택 (0x4, 0x508200, 0x0, 0x0, 0x0) = 1 0
읽기 (0x3, "$ \ 222 \ 351 {L \ 363 \ 261 \ 25063sN \ 216 \ 300 @ q7 \ 203 \ 276b \ 257 \ 354 \ 337 \ 356 \ 260! {\ 342 \ 017 \ 271 = \ 222, \ 245 \ 347t \ 006 \ 225 \ 257 \ 333; \ 204 \ 020] \ 242 \ 005z # \ 0 ", 0x2000) = 48 0
쓰기 (0x2, "debug2 : service_accept : ssh-userauth \ r \ n \ 0", 0x26) = 38 0
connect (0x4, 0xBFFFEEA2, 0x6A) = 0 0
쓰기 (0x4, "\ 0", 0x4) = 4 0
쓰기 (0x4, "\ v5 \ 004 \ 0", 0x1) = 1 0
읽기 (0x4, "\ 0", 0x4) = -1 Err # 4

그것은 무언가를 읽으려고 노력하고있는 것 같습니다. 누군가 제안이나 아이디어가 있다면 매우 감사하겠습니다!

ssh 클라이언트가 귀하의 계정에 대해 정지하지만 다른 계정 (루트)에 대해서는 정지되지 않은 이유는 아마도 ssh 에이전트에 문제가 있기 때문일 것입니다. 중 하나는 ssh-agent실행되지 않았거나 구성이 어떤 식 으로든 잘못이다.

이를 확인하려면 다음을 시도하십시오.

unset SSH_AUTH_SOCK
ssh mylogin@myremoteserver.com

ssh_key에 암호 문구를 입력하라는 메시지가 표시되면 ssh-agent에 문제가 있음을 의미합니다.

이 관련 질문에 대한 내 게시물을 참조하십시오 .

리버스 DNS에 관심이 있습니까?

기본적으로 클라이언트는 서버에서 역방향 DNS를 수행하거나 그 반대로 수행합니다.

나는 시험을 제안한다 :

/ etc / ssh / sshd_config를 편집하고 "UseDNS"가 "no"로 설정되어 있는지 서버에서 DNS 조회를 비활성화하십시오.

"service ssh reload"(또는 ssh 데몬이 구성을 다시 읽게하는 원인)를 실행 한 다음 다시 시도하십시오.

우연히도 오랜 시간이 지난 후에 마침내 프롬프트를 표시하지는 않습니까?

확인해야 할 또 다른 사항은 서버에서 / etc / hosts의 내용을보고 잘못된 것이 없는지 확인하는 것입니다.

~ / .ssh 디렉토리 및 파일에 대한 권한을 확인하십시오. 기본 umask는 너무 관대하며 파일을 다시 만들 때 실수로 파일에 잘못된 권한을 부여했을 수 있습니다. 나는 이것으로 몇 번 화상을 입었다. 내가 사용한 ssh 클라이언트 (또는 서버) 중 어느 것도 이것에 관한 유용한 오류 메시지를 제공하지 않았습니다 ...

클라이언트와 서버에 디스크 여유 공간이 있습니까?

df -h

나는 비슷한 문제가 있었다.

ssh domain.ip:user.name

로그인 이름을 강제로 입력하여 문제를 무시할 수있는 것 같습니다.

ssh -v domain.ip -l user.name

나를 위해 Snow Leopard로 업그레이드하면 문제가 해결되었습니다. OSX의 버그와 관련이 있다고 생각합니다.

키가 저장되어 있으면 known_hosts 파일의 ~ / .ssh 디렉토리에서 키를 삭제할 수 있습니다. 항목을 찾아서 삭제하면 다시 프롬프트가 표시됩니다.

반면에, 호스트가 기록 된 것과 일치하지 않으면 경고를 표시해야합니다.

OS X에서 호스트 이름 조회가 실패한 것처럼 작동하는 문제가 있습니다. 연결 대기 시간이 너무 길어 지거나 프롬프트가 표시되면 대기 시간이 길어 지므로 연결을 끊기 전에 암호를 입력하는 데 약 10 초가 걸립니다. 사람들이 문제의 호스트를 호스트 파일에 추가하도록 제안하더라도 불구하고 추적 할 수 없었습니다. 나는 그것이 단지 "OS X의 DNS 조회로 인한 결함"일 것이라고 생각하고 그것을 용인 할 것으로 예상되었습니다.

서버의 로그를 확인하십시오. 일반적으로 /var/log/auth.log(Debian / Ubuntu) 또는 /var/log/secure(RedHat / CentOS)에 있습니다. 연결에 대한 모든 문제는 일반적으로 거기에 기록됩니다.

/ etc / hostname이 개행으로 끝나는 지 확인하십시오.