사용 가능할 때 SSH가 로컬 SOCKS 리스너를 쓰게 하기

OpenSSH Match exec 검사를 하나의 목적지로 한정하고, 로컬 포트 검사가 성공해도 무엇이 증명되고 무엇이 증명되지 않는지 정리합니다.

로컬 SOCKS 리스너는 일부 네트워크에서는 유용하지만 다른 네트워크에는 없습니다. OpenSSH는 프록시 명령을 조건부로 선택할 수 있으므로 그 선택을 모든 호스트에 적용하지 않아도 됩니다.

OpenBSD 형식의 nc을 쓰는 OpenSSH에서 예시 클라이언트 구성은 다음과 같습니다.

Host work-server
    HostName ssh.example.net
    User alex

Match originalhost work-server exec "nc -z -w 1 127.0.0.1 1080"
    ProxyCommand nc -X 5 -x 127.0.0.1:1080 %h %p

Match all

originalhost은 검사를 SSH 명령줄에서 지정한 이름으로 한정합니다. exec은 해당 명령이 성공적으로 끝날 때 일치합니다. 마지막 Match all은 뒤따르는 설정에 대해 그 조건부 범위를 끝냅니다.

이는 앞서 적용된 어떤 설정도 이미 충돌하는 프록시 명령이나 점프 경로를 선택하지 않았다고 가정합니다. SSH는 보통 설정 옵션에 대해 처음 얻은 값을 사용하므로, 위쪽의 넓은 기본값이 뒤의 조건이 기대한 효과를 내지 못하게 할 수 있습니다.

수신 대기 중인 소켓은 소박한 약속

이 검사는 로컬 포트로의 TCP 접근을 확인합니다. SOCKS 협상을 완료하지도, 원하는 목적지 연결을 수립하지도, 어느 프로그램이 그 포트를 소유하는지 증명하지도 않습니다. 검사 후에 리스너가 사라질 수도 있습니다.

시간 제한은 실패한 검사를 일정 범위에 머물게 합니다. 표시된 옵션은 OpenBSD nc 인터페이스의 것이며, 같은 파일 이름을 쓰는 다른 프로그램은 다른 옵션을 제공할 수 있습니다.

조건이 일치하지 않으면 이 예시는 연결에 이 ProxyCommand를 적용하지 않고 평소 경로를 허용합니다. 그것이 적절한 것은 직접 접근이 허용될 때뿐입니다. 필수 프록시 정책에서는 가용성 검사를 다른 경로로 빠져나갈 허가로 써서는 안 됩니다.

대상 SSH 호스트 이름과 호스트 키 검사는 여전히 목적지 서버를 식별합니다. 전송 보조 수단을 고르는 것은 예상치 못한 호스트 키를 받아들일 이유가 아닙니다.

관련 글