신뢰할 수 없는 VPN에서 당신의 SSH 비밀번호를 실제로 보는 사람은 누구인가
VPN으로 비밀번호를 입력하기 전에 신원 확인을 수행하고, 그다음 서버 신원, 사용자 인증, 엔드포인트 신뢰를 세 가지 결정으로 나누십시오.
직접 운영하지 않는 VPN으로 SSH 세션을 보내도 비밀번호는 여전히 SSH 서버의 것이지 중간 네트워크의 것이 아닙니다. 검증된 호스트로 가는 전송이 제대로 보호된다면, 그 경로의 수동적 관찰자는 비밀번호를 읽을 수 있는 형태로 얻지 못합니다. 그러나 조건 하나를 바꾸면 답도 달라집니다. 검증되지 않은 호스트, 약화된 암호 목록, 침해된 워크스테이션은 각각 다른 결과를 냅니다. 아래 확인을 순서대로 수행하고, 각각을 중단 조건으로 다루십시오.
무언가를 입력하기 전에 수신자를 지목하십시오
비밀번호 필드는 인증 메시지 안에서 이동하고, 그 메시지는 암호화된 전송 안에서 이동합니다. 기밀성은 전송의 속성이므로, 보호가 협상되었는지 그리고 의도한 호스트와 협상되었는지에 달려 있습니다. 사람들이 건너뛰는 것이 바로 그 두 번째 절반입니다. 사기꾼에게 암호화된 연결은 기밀인 동시에 쓸모없습니다. VPN 로그인은 SSH 호스트에 대해 아무것도 증명하지 않으며, 제공자의 평판은 키 확인을 대신하지 못합니다.
두 방향을 머릿속에서 분리하십시오. 호스트 키는 어느 서버에 도달했는지에 답합니다. 비밀번호나 키 인증은 서버가 어느 사용자를 받아들이는지에 답합니다. 두 번째를 개선해도 첫 번째는 절대 고쳐지지 않습니다.
호스트 신원, 기록, 협상을 확인하십시오
클라이언트에서 이미 가진 기록으로 시작하십시오. 신뢰할 수 있는 출처와 비교한 공개 지문, 그리고 여전히 일치하는 known_hosts 항목이 인증이 시작되기 전에 중요한 유일한 증거를 줍니다.
ssh-keygen -F ssh.internal.example.net -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=yes ssh.internal.example.net
서버 쪽에서는 공개하려는 지문을 기억에서 복사하지 말고 출력하십시오. 그것을 경로 밖에서 배포하는 것이 요점입니다. 호스트 이름과 같은 채팅 경로에서 붙여 넣은 지문은 둘 다 같은 곳에서 왔다는 것만 증명합니다.
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo sshd -T | grep -E 'hostkey|kexalgorithms|cipher'
협상된 알고리즘은 양쪽의 교집합에서 나옵니다. 클라이언트 구성이 오래된 장치에 닿기 위해 구식 키 교환을 고정하면, 그 선택은 그것이 대화하는 모든 호스트에 적용되므로 전역이 아니라 그 호스트로 범위를 좁히십시오.
서버가 실제로 받아들이는 방식을 읽으십시오
서버가 어떤 인증 방식을 허용하는지 알면 비밀번호가 무엇을 위한 것인지 알 수 있습니다. 공개 키만 받아들이는 호스트에는 보호할 비밀번호 교환이 없고, 여전히 비밀번호를 받아들이는 호스트는 물려받은 기본값이 아니라 의도적인 결정을 받을 자격이 있습니다.
sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'
사용자를 키 인증으로 옮기면 그 사용자의 비밀번호가 그 교환에서 빠집니다. 그것이 침해된 워크스테이션을 안전하게 만들지도, 신뢰할 수 없는 원격 세션을 무해하게 만들지도 않습니다. 서로 다른 통제가 필요한 서로 다른 위험입니다. 에이전트 전달도 결정하십시오. 신뢰할 수 없는 호스트로 에이전트를 전달하면 세션이 지속되는 동안 그 호스트가 당신의 키를 쓸 수 있게 되며, 이는 모든 것을 시작한 비밀번호 문제보다 큰 노출입니다.
호스트 키 경고를 사고 단계로 다루십시오
클라이언트가 호스트 식별이 바뀌었다고 경고하면 멈추고 같은 네트워크 경로를 지나지 않는 경로로 확인하십시오. 지문을 서버 콘솔이나 그것을 다시 구축한 운영자와 비교하십시오. 경고를 잠재우려고 오래된 항목을 지우는 것이 거부해야 할 유일한 행동입니다. 그것은 증거를 버리고 가능한 가로채기를 평범한 로그인으로 바꿉니다.
호스트가 정당하게 다시 구축되었다면 새 지문이 확인된 뒤에만 오래된 항목을 제거하고, 그다음 다시 연결해 협상을 다시 확인하십시오. 변경을 날짜와 이유와 함께 기록하십시오. 다음 사람이 같은 경고를 보게 되고 그것이 해결되었다는 것을 알아야 하기 때문입니다.
이 안내서가 다루지 않는 것
트래픽을 지켜보는 VPN 운영자는 당신의 기계에서 로컬 권한을 가진 소프트웨어와 같지 않습니다. 엔드포인트 침해, 적대적인 브라우저 확장, 키보드 기록기는 SSH가 협상할 수 있는 모든 것 아래에 있으며, 어떤 터널도 그것을 바꾸지 않습니다. 워크스테이션이 의심스럽다면 다른 출구로 다시 연결해 비밀성을 시험하는 대신 사고 절차를 따르십시오. 다시 연결하는 것은 경로가 바뀌었다는 것을 증명할 뿐 엔드포인트에 대해서는 아무것도 증명하지 않습니다.
평범한 경우로 마무리하십시오. 검증된 호스트, 보호된 전송, 의도적으로 고른 인증 방식, 필요하지 않은 전달은 하지 않는 것. 그 조합이 제목의 질문에 대한 답이며, 그것은 하나가 아니라 네 가지 결정입니다.