잘못된 서버에 연결하려고 할 때 SSH 비밀번호가 표시됩니까?

192

실수로 비밀번호 자격 증명으로 잘못된 서버에 연결하려고하면 관리자가 사용한 비밀번호를 읽고 기록 할 수 있습니까?

ssh password

— vfclists
소스

11

— jamesdlin

41

ssh 클라이언트에서 먼저 서버를 인증하고 "이 서버에 비밀번호를 알려줄 수 있다고 신뢰합니다"라고 말합니다. 다음에 가장 먼저 본 메시지에주의를 기울이십시오. "X의 진위를 확인할 수 없습니다. RSA 키 지문은 Y입니다. 확실합니까? (예 / 아니요)"이 성가신 질문은 의심 할 여지가 없습니다. 매번 자동으로 예라고 대답 합니다 .

— kubanczyk

6

PasswordAuthentication noOpenSSH에서 기본적 으로 설정이 가능 하며 신뢰할 수있는 서버에 대해서만 활성화 할 수 있습니다 (필요한 경우). 엄격한 호스트 키 검사와 결합 하면 물론 비용 부담으로 암호가 노출 되는 것을 방지 할 수 있습니다.

— hobbs

6

@kubanczyk, "internal-www.my-company.com"으로 SSH를 원했지만 실수로 "ssh www.my-company.com"에 입력하면 프롬프트가 보호되지 않습니다. 두 서버가 모두 신뢰할 수있는 목록에서, 그중 하나는 귀하가, 다른 하나는 제 3자가 운영하는 것입니다.

— Mark

@hobbs ChallengeResponseAuthentication no도 생각합니다

— ilkkachu

215

간단한 예 : 예

자세한 세부 사항...

내 컴퓨터에 연결하면 일반 ssh서버를 실행 중인지 또는 전달되는 비밀번호를 기록하도록 수정 된 서버를 알 수 없습니다 .

또한 반드시 수정 할 필요는 sshd없지만 pam_script비밀번호를 전달 하는 PAM 모듈 (예 :)을 작성할 수 있습니다.

예. 절대 신뢰할 수없는 서버로 암호를 보내지 마십시오 . 시스템 소유자는 모든 시도 된 비밀번호를 기록하도록 시스템을 쉽게 구성 할 수 있습니다.

(실제로 이것은 infosec 세계에서는 드문 일이 아닙니다. 시도한 암호를 기록하도록 허니팟 서버를 설정하십시오)

— 스티븐 해리스
소스

13

옳은. 기본적으로 표준 sshd은 비밀번호를 기록 하지 않습니다 . (암호를 로그인 이름으로 입력하면 기록되지만 다른 문제입니다). 이 표준은 sshd보안 도구 등이 :-) 같은 자격 증명을 기록하지 않습니다

— 스티븐 해리스

116

공개 / 개인 키 쌍을 사용해야하는 또 다른 이유는 다음과 같습니다.

— gerrit

3

한동안 비밀번호를 사용하는 것에 대해 궁금해했으며 최근에 잘못된 서버에 로그온하는 것이 악의적 인 서버 관리자에게 비밀번호를 공개하는 좋은 방법이라는 생각이 들었습니다.

— vfclists

10

@vfclists가 잘못된 서버에 로그온하면 sshd 클라이언트가 각 서버의 지문을 저장하는 이유이기도합니다. 처음 연결하면 지문이 인식되고 나중에 지문이 일치하지 않으면주의해야 할 경고가 표시됩니다.

— hometoast

44

더 나은 조언 : ssh에 암호 인증 을 사용하지 마십시오 . 이 프로토콜에는 아주 좋은 이유로 pubkey auth가 있습니다. 그걸 써!

— R ..

52

예.

비밀번호는 암호화 된 연결이 설정된 후에 전송되지만 원격 서버는 비밀번호를 일반 텍스트로 가져옵니다.

당신이 그것에 관심이 있다면, 가장 쉽고 쉬운 해결책은 SSH 키를 사용하는 것입니다.

키를 사용할 수없는 컴퓨터가있는 경우 암호를 안전하게 저장하는 도구를 만든 다음 sshpass연결하는 서버에 따라 항상 올바른 암호를 보내는 데 사용 하는 방법이 있습니다.

이제 암호가 일반 텍스트로 전송되는 이유는 암호를 처리하고 저장하는 모든 결정을 원격 끝으로 남기고 클라이언트가 완전히 바보 일 수 있기 때문입니다. 지난 10 년 동안 Linux 및 BSD 시스템에서 사용 된 두 가지 다른 비밀번호 해싱 (스토리지) 형식 ( crypt (3) )이 있으며,이 중 어느 것도 클라이언트의 지원이 필요하지 않습니다.

그것은 부분적으로 역사 때문이기도합니다 (즉, 항상 그런 식입니다). 암호로도 사용할 수있는 더 나은 시도-응답 인증 프로토콜이 있습니다. 예를 들어 SRP 는 인증 중에 당사자에게 공유 비밀을 제공합니다. 일부 SSH 서버용으로 구현되었지만 OpenSSH 용 패치는 (매우) 이전 버전 용입니다.

— 일 카추
소스

1

비밀번호 인증을위한 챌린지 응답 프로토콜의 문제점 중 일부는 서버가 비밀번호를 일반 텍스트로 저장해야한다는 것입니다. 챌린지-응답 프로토콜이 서버가 해시 된 비밀번호를 저장할 수있게한다면, 매우 구체적인 해싱 알고리즘이 필요할 것입니다.

— kasperd

8

비밀번호는 일반적으로 "일반 텍스트"로 전송됩니다 (즉, 실제로는 명확하지 않지만 기본 SSH | TLS | 어떤 연결이 제공하는 보호 기능 만 사용). 시스템이 암호를 클라이언트 측에서 해시하고 해시를 보내도록 요청하면 서버는 실제 암호를 파생시킬 수 없으며 대신 암호 해시를 제공 할 수있는 사람에게 액세스 권한을 부여하여 해시 암호와 동일

— Blacklight Shining

1

@BlacklightShining 지식이없는 암호 증명은 존재하지만 표준 암호 데이터베이스를 사용하는 방법이없고 키 기반 인증이 아니라 암호를 사용하는 실질적인 지점이 없기 때문에 SSH에는 사용되지 않습니다.

— Random832

인증에 사용 된 비밀번호는 어디에서 볼 수 있습니까? 그들은 /var/log/auth.log에 있지 않습니다.

— アレックス

OpenSSH는 암호를 기록하지 않거나 실패하거나 그렇지 않습니다. (다른 SSH 서버에는 익숙하지 않습니다.) 거의 모든 합법적 인 설치에서 의도적으로 암호를 기록 할 때 발생하는 위험으로 인해 제공 할 수있는 모든 가치가 중요 할 수 있습니다. 또는 일반 텍스트로 틀리지 만 올바른 비밀번호를 시도했습니다. 하지만 이렇게해야 할 이유가 있다면 OpenSSH를 패치하기가 쉽습니다.

— musicinmybrain

10

Stephen Harris의 답변을 바탕으로 ssh (일종의 허니팟)를 통해 상자에 연결할 때 수정 된 PAM 인증 스크립트가 캡처 할 수있는 것을 보여주는 실시간 뷰가 있습니다. PAM 라이브러리 lib-storepw의 수정 된 버전을 사용합니다.

https://livesshattack.net

https://livesshattack.net/about

— 윌리 S.
소스

4

링크를 사용할 수없는 경우를 대비하여 주로 링크 인 답변이 눈살을 찌푸립니다. 독자를위한 인증 스크립트를 사용하여이를 관리 한 방법을 약간 설명해야합니다.

— Centimane

그것의 더 이상 작동하지 않습니다, 나는 암호로 큰 문자열을 보냈습니다, 나는 그것을 깨뜨릴 수 있다고 생각합니다, 죄송합니다 :-/

— scottydelta

@scottydelta 살펴 보지 않았지만 PAM 모듈 또는 SSH 데몬 자체가 인증 시도에서 허용 할 수있는 암호 크기에 버퍼 제한이있을 수 있습니다. 사이트는 여전히 의도 한대로 작동하지만 실제로는 sshd 또는 PAM 모듈이 허용하는 버퍼 한계까지 처리 할 수 있습니다.

— Willie S.

다른 사람이 사용할 수있는 수정 된 lib-storepw의 소스가 관심이 없습니까?

— Tim Fletcher

2

SSH는 상호 신뢰가 필요한 프로토콜입니다. 그렇기 때문에 OpenSSH 클라이언트가 known_hosts 파일을 유지 관리하여 첫 번째 사용 체계에 대한 신뢰를 구현합니다.

소프트웨어를 제공 한 사람 또는 소프트웨어가 어떤 로그 기록을 구성했는지에 관계없이 SSH 서버에 로그온을 시도하면 일부 인증 절차에 참여하게됩니다. 비밀번호 인증을 사용하는 경우 해당 서버로 비밀번호를 전송합니다. 이것이 비대칭 암호화 (공개 키, 인증서)가 권장되는 이유 중 하나입니다. 공개 키 암호화는 자격 증명 공개 위험을 크게 줄입니다. (ssh-agent 전달 또는 이와 유사한 체계를 사용하는 경우 MitM 공격으로부터 보호되지 않을 수 있습니다.)

— jvoorhis
소스

SSH에는 상호 트러스트 나 대칭 트러스트가 필요하지 않습니다. 알고 있어야합니다. known_hosts는 신뢰가 아니라 진정성에 관한 것입니다. 알다시피, 신뢰할 수없는 호스트에 공개 키를 배치하는 것이 안전합니다. 실제로 비밀번호를 사용하여 로그인하지 않으면 "안전한"비밀번호가 사용됩니다. (물론 서버를 신뢰하는 정도만큼 안전합니다.) 호스트 기반 ssh 로그인조차도 비대칭 신뢰에 의존합니다.

— markhahn