실수로 비밀번호 자격 증명을 사용하여 잘못된 서버에 연결하려고 하면 관리자가 사용하는 비밀번호를 읽고 기록할 수 있습니까?
답변1
간단히 말해서: 예
자세한 내용은...
ssh내 컴퓨터에 연결하면 내가 일반 서버를 운영하고 있는지, 아니면 전달되는 비밀번호를 기록하도록 수정된 서버를 운영하고 있는지 알 수 없습니다 .
또한 반드시 수정할 필요는 없지만 비밀번호를 전달하는 sshdPAM 모듈(예: 을 사용하여)을 작성할 수 있습니다 .pam_script
그렇죠. 안 돼요신뢰할 수 없는 서버에 비밀번호를 보내세요. 기계 소유자는 모든 시도된 비밀번호를 기록하도록 쉽게 구성할 수 있습니다.
(실제로 이는 정보 보안 세계에서는 드문 일이 아닙니다. 시도된 비밀번호를 기록하도록 허니팟 서버를 설정하십시오.)
답변2
예.
암호화된 연결이 설정된 후 비밀번호가 전송되지만 원격 서버는 비밀번호를 일반 텍스트로 가져옵니다.
이것이 걱정된다면 가장 좋고 쉬운 해결책은 SSH 키를 사용하는 것입니다.
sshpass컴퓨터가 키를 받아들일 수 없는 경우 한 가지 해결 방법은 비밀번호를 안전하게 저장한 다음 연결 중인 서버에 따라 항상 올바른 비밀번호를 보내는 도구를 만드는 것입니다 .
이제 비밀번호가 일반 텍스트로 전송되는 이유는 비밀번호 처리 및 저장에 대한 모든 결정을 원격 측에 맡기고 클라이언트가 완전히 바보가 될 수 있기 때문입니다. 지난 10여 년 동안 Linux 및 BSD 시스템에서는 여러 가지 비밀번호 해싱(저장) 형식이 사용되었습니다(크립트(3)), 어느 것도 클라이언트 지원이 필요하지 않습니다.
이것의 일부는 역사적이지만(즉, 항상 이런 식이었습니다). 비밀번호를 사용할 수도 있는 더 나은 시도-응답 인증 프로토콜이 있습니다. 예를 들어권장 소매가, 인증 중에 모든 당사자에게 공유 비밀을 제공합니다. 일부 SSH 서버에는 이미 구현되어 있지만 OpenSSH에는 (매우) 이전 버전에 대한 패치가 있습니다.
답변3
Stephen Harris의 답변을 바탕으로 SSH를 통해 상자(일종의 허니팟)에 연결할 때 수정된 PAM 인증 스크립트가 캡처할 수 있었던 내용을 보여주는 라이브 보기가 있습니다. 나는 PAM 라이브러리 lib-storepw의 수정된 버전을 사용합니다.
답변4
SSH는 상호 신뢰가 필요한 프로토콜입니다. 이것이 바로 OpenSSH 클라이언트가 처음 사용할 때 신뢰 체계를 구현하기 위해 Known_hosts 파일을 유지 관리하는 이유입니다.
소프트웨어를 제공한 사람이 누구인지, 소프트웨어가 어떤 데이터를 기록하도록 구성했는지에 관계없이 SSH 서버에 로그인하려고 하면 일부 인증 프로세스에 참여하게 됩니다. 비밀번호 인증을 사용하면 비밀번호를 서버로 전송합니다. 이것이 비대칭 암호화(공개 키, 인증서)를 사용하는 것이 권장되는 이유 중 하나입니다. 공개 키 암호화는 자격 증명이 손상될 위험을 크게 줄여줍니다. (단, SSH 프록시 전달이나 유사한 방식을 사용하는 경우 MitM 공격으로부터 보호되지 않을 수 있습니다.)