SSH ProxyCommand와 호스트 기반 인증: 어느 호스트가 서명하는가?

호스트 기반 인증이 관련될 때 배스천을 통해 TCP 스트림을 전달하는 것과 그곳에서 두 번째 SSH 클라이언트를 시작하는 것을 구분합니다.

대상은 배스천에서 오는 TCP 연결을 보지만, 인증을 수행하는 SSH 클라이언트는 여전히 워크스테이션에서 실행됩니다.

Host behind-bastion
    ProxyCommand ssh -W %h:%p bastion

여기서 도우미는 배스천에 로그인해 자신의 SSH 서버에 대상으로 전달되는 연결을 요청합니다. 워크스테이션의 외부 SSH 클라이언트가 그 스트림을 통해 대상의 SSH 프로토콜을 주고받습니다. 배스천은 전송을 제공할 뿐, 대상을 향한 SSH 클라이언트를 시작한 것은 아닙니다.

이 구분은 호스트 기반 인증에서 중요합니다. OpenSSH의 ssh-keysign 도우미는 필요한 서명을 만들기 위해 로컬 호스트 키에 접근합니다. 네트워크 원본 주소가 배스천에 속한다고 해서 워크스테이션이 배스천의 호스트 키로 서명하게 되지는 않습니다.

다음과 비교해 보십시오:

ssh -t bastion ssh target

이것은 배스천에서 또 다른 SSH 프로그램을 시작합니다. 그 로컬 구성과 사용 가능한 호스트 키는 해당 머신에 속하므로, 배스천에서 대상으로 이미 구성된 호스트 기반 신뢰 관계에 참여할 수 있습니다. 그래도 대상의 해당 권한 부여와 이름 확인은 필요합니다.

두 번째 형태는 세션 동작 방식도 바꿉니다. 원격 명령을 실행하고 터미널을 사용합니다. 모든 SSH 파일 전송이나 자동화 전송을 위한 투명한 대체 수단은 아닙니다. 원본 주소가 충분해 보이도록 서버의 신뢰 검사를 약화하기보다는, 어느 머신이 대상에 인증해야 하는지에 따라 구성을 선택하십시오.

관련 글