☰

ProxyCommand 및 netcat 모드를 사용할 때 SSH가 구성에서 호스트 이름을 확인하도록 허용

tag-icon • tag-icon ssh proxy
ProxyCommand 및 netcat 모드를 사용할 때 SSH가 구성에서 호스트 이름을 확인하도록 허용

SSH 연결 수신 거부에 대한 몇 가지 일반적인 옵션을 설정하려고 합니다. 내 ~/.ssh/config파일은 다음과 같이 축약되어 있습니다.

Host *%via
  ProxyCommand ssh gateway -W $(echo %h | cut -d%% -f1) %p

Host gateway
  HostName gateway.example.com
  User username
  ForwardAgent yes
  IdentityFile keypathg

Host target
  User username
  HostName target.example.com
  IdentityFile keypatht

*%via별칭을 사용 하면 Host다음과 같은 결과를 얻습니다.

% ssh -vvv target%via
OpenSSH_5.9p1, OpenSSL 0.9.8y 5 Feb 2013
debug1: Reading configuration data /Users/myuser/.ssh/config
debug1: /Users/myuser/.ssh/config line 5: Applying options for *
debug1: /Users/myuser/.ssh/config line 12: Applying options for *%via
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: auto-mux: Trying existing master
debug1: Control socket "/Users/myuser/.ssh/tmp/target%via_22_myuser" does not exist
debug2: ssh_connect: needpriv 0
debug1: Executing proxy command: exec ssh -A gateway -W $(echo target%via | cut -d% -f1):22
debug1: permanently_drop_suid: 501
debug1: identity file /Users/myuser/.ssh/id_rsa type -1
debug1: identity file /Users/myuser/.ssh/id_rsa-cert type -1
debug1: identity file /Users/myuser/.ssh/id_dsa type -1
debug1: identity file /Users/myuser/.ssh/id_dsa-cert type -1
ssh_exchange_identification: Connection closed by remote host

그러나 내가 사용하면

% ssh target.example.com%via

대상 서버에 액세스했지만 잘못된 사용자로 공개키 인증 없이 액세스했습니다.

나생각하다이 시점에서 내 질문은 사용 시 이 ForwardAgent수신 거부 방법이 내 SSH 구성/환경 전체를 통과할 것인지, 아니면 키만 통과할 것인지입니다. 단지 열쇠라면 전자를 어떤 식으로든 악용할 수 있을까요?

내 SSH 버전은 5.9v1, 게이트웨이는 5.9v1, 대상은 5.3p1입니다. 나는 -W이것이 5.4에서 소개되었다고 생각합니다. 그러나 그것은 마지막 상자에서는 중요하지 않습니다. 그렇죠? 올드 스쿨을 사용하는 것은 nc별반 다를 것 같지 않습니다.

줄의 각 상자에 수동으로 SSH를 연결할 수 있음을 확인했습니다. 이렇게 하면 게이트웨이에서는 할 수 없지만 ssh target할 수 있기 때문에 호스트 이름 별칭 정보가 전달되지 않는다는 것을 알 수 있습니다 ssh target.example.com. 이는 공개 키 인증에 적용됩니다. 게이트웨이와 대상의 사용자 이름이 우연히 동일하므로 푸시 구성 없이 작동합니다.

또는 유사한 구성으로 이 정보를 푸시할 수 없는 경우 ForwardAgent이 정보가 포함된 게이트웨이에 .ssh/config를 유지하는 가장 현명한 해결 방법은 무엇입니까?

답변1

와, 이런 질문을 해주셔서 감사합니다. SSH를 최대한 활용하는 사람은 거의 없으며 문제는 여러 영역으로 나누어집니다.

이것은 ProxyCommand문제가 되지 않습니다. 이는 ProxyCommand단순히 원격 클라이언트와 통신을 시도하기 전에 몇 가지 준비를 수행하도록 로컬 SSH 클라이언트에 지시합니다. 예, 이 인스턴스에서는 다른 SSH 세션과 통신하고 있지만 해당 세션은 단순히 -W입력을 받아 다른 시스템으로 전달합니다. SSH 세션을 완전히 독립적으로 준비한다고 생각할 수 있습니다. 피할 수 없는 자동차 비유: A 지점에서 B 지점으로 이동하기 위해 페리를 타야 하는지 여부에 관계없이 자동차는 동일한 자동차입니다.

이것은 ForwardAgent문제가 되지 않습니다. ForwardAgent로컬 클라이언트가 원격 세션의 컨텍스트에서 로컬 키를 사용할 수 있도록 하는 기능을 제공하도록 합니다. 원격 세션 설정이 완료되지 않았습니다.

이는 .ssh/config형식 문제입니다. 두 번째와 세 번째 줄은 debug1입니다. 당신 은 .ssh/config이것이 $ ssh target.example.com%via작동하지만 사용자 이름과 키가 잘못되었음을 알았습니다. 음, 섹션을 Host target읽을 수 없습니다(올바른 사용자 이름과 키 파일을 제공함). 어떤 섹션이 사용됩니까? *그리고 *%via.

이러한 옵션을 어떻게 전달합니까? 흥미롭게도 와일드카드는 길이가 0인 문자열과 일치합니다. , 및 와 Host target*일치합니다 .targettarget%viatarget.example.comtarget.example.com%via

그래서 당신은 질문을 합니다. 기계에 .ssh/config도움말 gateway이 설정됩니까? 아니 난 할 수 없어. 결코 읽히지 않을 것입니다. 모든 일은 로컬 컴퓨터에서 발생합니다.

내가 설명하는 것은 왜 $ ssh target.example.com%via작동하지 않는지에 대한 대답입니다.

당신은 그것을 선호합니다 $ ssh target%via. 그게 더 편한건 사실이에요. 호스트 이름으로 target확인되지 않았기 때문에 축약된 형식이 실패했습니다 . SSH가 분출하지 않는 이유는 무엇입니까 ssh: Could not resolve hostname target: Name or service not known? 왜냐하면 ProxyCommand그것이 성공적으로 확립되었기 때문이다. SSH 연결 요소가 설정되었지만 예상치 못한 곳에서 호스트 이름 오류가 발생하므로 보다 일반적인 메시지를 내보냅니다. 디버깅 정보를 개선할 수 있는 부분을 파악하는 데 도움이 되도록 이에 대한 버그 보고서를 제출하겠습니다.

마지막 댓글:

나는 그것의 구문을 좋아한다 Host *%via. 깔끔하면서도 유연해요. 전에 본 적이 있는데 Host *+*첫 번째 부분과 마지막 부분을 사용하여 %h(ost)어디로 가야 할지 결정합니다. 하지만 이것을 이해하려면 더 열심히 노력해야 합니다. 관련된:http://wiki.gentoo.org/wiki/SSH_jump_host

관련 정보