기본적으로 전체 질문은 제목에 있습니다. ssh가 네트워크를 통해 비밀번호를 보내나요? 물론 이는 사용자 이름과 비밀번호를 통해 로그인한다고 가정합니다.
SSH가 네트워크를 통해 비밀번호를 보내지 않으면 사용자가 소위 호스트를 Known_hosts 파일에 추가하더라도 중간자(man-in-the-middle)가 사용자의 비밀번호를 얻을 수 없기 때문에 이것을 묻습니다.
이렇게 되어야 한다고 하시는 분들도 계셔서 댓글에 반례를 적어봤습니다. 그 밖에 어떻게 작동할 수 있는지에 대한 질문이 지금 반복적으로 나타나기 때문에 여기에 해당 리뷰를 복사하고 있습니다.
서버는 클라이언트에게 사용할 해시를 알려줄 수 있습니다. [서버 섀도우 파일의 비밀번호를 해시하는 데 사용된 것과 동일한 해시 값입니다. ] 그러면 클라이언트는 서버의 섀도우 파일에 있어야 하는 해시 ψ를 계산할 수 있지만 서버에서는 이를 해시 ψ'라고 부릅니다. 따라서 서버와 클라이언트 모두 ψ를 알고 있습니다. 그런 다음 클라이언트는 임의의 솔트 σ를 선택하고 .
(hash(ψ.σ), σ)(연결 연산자는 어디에 있습니까)를 서버에 보낼 수 있습니다. 그런 다음 서버는 ψ'.σ를 해시하고 클라이언트로부터 받은 튜플의 첫 번째 요소가 해당 해시와 일치하는지 확인합니다. 그렇다면 클라이언트는 비밀번호를 알고 있습니다.
답변1
예. 비밀번호는 암호화된 연결을 통해 일반 텍스트로 원격 서버에 전송됩니다.
일반적인 인증 방법은 서버가 비밀번호의 해시를 계산하여 서버에 저장된 값과 비교하는 것입니다. 해시를 저장하는 방법에는 여러 가지가 있으며 현재 구현에서 클라이언트는 서버가 무엇을 사용하는지 전혀 모릅니다. (crypt
예를 들어 매뉴얼 페이지를 참조하십시오.). (그렇다고 하더라도 단순히 비밀번호의 해시를 전송하면 해시가 비밀번호와 동일해집니다.)
또한 서버가 PAM을 사용하는 경우 PAM 모듈은 인증을 구현하기 위해 거의 모든 방법을 사용할 수 있으며 그 중 일부에는 일반 텍스트 비밀번호가 필요할 수 있습니다.
그러나 공개 키로 인증하면 해당 키가 원격 호스트로 전송되지 않습니다. (이에 대한 설명과 링크는security.SE에 관한 질문)
다음과 같은 비밀번호 기반 인증 알고리즘도 있습니다.권장 소매가, 비밀번호를 일반 텍스트로 상대방에게 보낼 필요가 없습니다. SRP는 OpenSSH용 외부 패치로만 구현되는 것 같습니다.
답변2
비밀번호 인증을 사용하는 경우 SSH는 네트워크를 통해 비밀번호를 보냅니다. 연결은 암호화되어 도청자가 비밀번호를 볼 수 없습니다. "...의 진위를 확인할 수 없습니다." 메시지를 무작정 클릭하지 않으면 연결이 인증됩니다. 따라서 귀하의 비밀번호는 합법적인 서버 이외의 누구에게도 전송되지 않습니다.
"왜"에 대한 지루한 대답은,SSH 프로토콜필요.
덜 지루한 대답은 비밀번호 인증이 이런 방식으로 작동해야 한다는 것입니다. 이러한 방식으로 작동하지 않는 인증 수행 방법도 있지만 이는 더 이상 단순한 비밀번호 인증이 아닙니다.
단순 비밀번호 인증보다 더 발전된 대부분의 인증 프로토콜의 좋은 특징은 클라이언트가 비밀 데이터를 서버에 보내지 않는다는 점입니다. 이는 악의적인 서버가 제3의 서버에서 사용자를 가장하기 위해 사용할 수 있습니다. SSH 사용공개키 인증비밀번호 외에 가장 일반적인 SSH 인증 방법인 이 방법은 클라이언트가 세션 식별자(개인 키 필요)가 포함된 데이터 서명을 보내기 때문에 작동합니다. 악의적인 서버가 제3자 서버에 인증을 시도하면 데이터를 생성해야 합니다. 클라이언트에 보관된 개인 키 없이는 수행할 수 없는 다른 세션 식별자를 포함하는 서명입니다.
공개 키 인증을 사용하고 키를 사용하기 위해 비밀번호를 입력해야 하는 경우 이는 비밀번호 기반 인증이 아닙니다. 키를 사용하는 암호는 클라이언트 측에서만 키 파일에서 키를 읽는 데 사용됩니다. 공개 키 인증을 사용할 때 서버는 키가 암호화된 파일에 저장되어 있는지 여부를 알거나 신경 쓰지 않습니다.
비밀번호 인증을 위해서는 비밀번호를 서버로 보내야 합니다. 비밀번호 자체 대신 비밀번호 해시를 보내는 것은 도움이 되지 않습니다. 왜냐하면 비밀번호가 해시가 되기 때문입니다. 공격자는 실제 비밀번호를 찾을 필요가 없고 해시만 찾을 필요가 있습니다. 공격자할 수 있다공격은 실제 비밀번호를 조회하는 방식으로 이루어지기 때문에 개선이 되지 않습니다. 그러나 공격자가 제안한 체계에서 해시를 찾았지만 비밀번호를 찾지 못한 경우에는 그것으로 충분합니다. 반면, 일반적인 비밀번호 기반 인증의 경우 공격자는 비밀번호를 알아야 하며, 해시를 아는 것만으로는 충분하지 않습니다. 비밀번호가 충분히 강력하면 공격자는 해시에서 비밀번호를 찾을 수 없습니다. 실제로 공격자가 해시는 알지만 비밀번호는 알 수 없는 이유는 공격자가 보호되지 않은 백업이나 서버의 취약점을 통해 서버에서 비밀번호 해시 데이터베이스를 추출할 수 있었기 때문입니다. 웹사이트의 이러한 취약점은 종종 뉴스거리가 됩니다.
귀하가 제안한 계약은 표준 계약만큼 좋지 않습니다. 자신만의 암호화폐를 출시하지 마세요!
답변3
예, SSH는 네트워크를 통해 비밀번호를 전송하지만 종단간 암호화를 협상한 후에만 가능합니다. 섹션 8을 참조하세요.RFC 4252이는 비밀번호 확인 메시지에 다음 내용이 포함되어 있음을 의미합니다.plaintext password in ISO-10646 UTF-8 encoding [RFC3629]
답변4
SSH는 암호화된 채널 내에서 일반 텍스트로 네트워크를 통해 사용자 ID와 비밀번호를 보냅니다. 이것이 새 호스트에 연결할 때 키를 수락하라는 메시지가 표시되는 이유입니다. 호스트가 중간자 공격을 받는 것으로 알려진 경우 SSH는 이전 키를 삭제할 때까지 연결을 거부합니다.
일반 텍스트 비밀번호는 엔드포인트, 사용자 컴퓨터 및 원격 컴퓨터에서 사용할 수 있습니다. 비밀번호 인증을 비활성화할 수 있으며, 이 경우 비밀번호를 묻는 메시지가 표시되거나 원격 호스트로 전송되지 않습니다.
비밀번호로 보호된 키와 함께 키 기반 인증을 사용하는 것이 더 안전합니다. 원격 시스템에 키를 추가해야 합니다. 공개 키는 다양한 메커니즘을 통해 전송될 수 있는 텍스트 파일입니다. 키 기반 인증을 사용하는 경우 키 사용을 제한할 수 있습니다.