서버를 통해 로컬 네트워크 머신으로 SSH 터널링
centos-machine에 대한 외부 관리자를 위해 ssh 연결을 준비하고 싶습니다.
다음 설정 :
- HostA : 고정 IP 주소가있는 서버
- HostB : 로컬 -CentOS- 머신
- HostC : 외부 관리자 시스템
연결 레이아웃 : HostC > HostA > (Router) > HostB
HostB에서 다음 명령을 시도했습니다.
ssh -R Port:user@HostB:22 user@HostA
ssh user@HostB -p Port # --> Timeout here
라우터를 만지고 싶지 않습니다. 꼭 필요한 것은 아닙니다. HostA (linode-server)에 대한 ssh 연결이 제대로 작동합니다. Netstat는이 ( PORT가) 듣고 있음을 보여줍니다 . 그러나 두 번째 명령은 시간 초과됩니다. 이유가 무엇일까요?
HostC에서 연결하는 방법은 다음 명령이 작동합니까?
ssh -t HostA 'ssh HostB -p Port'
기타 조건 :
- 이미
GatewayPorts yesHostA로 설정 했습니다. - HostA는 키 파일을 통한 연결 만 허용합니다.
- HostA는 이미 HostB 및 HostC의 공개 키를 알고 있습니다.
- HostB는 ssh 기본 구성을 사용합니다.
- 모든 시스템의 Ufw 방화벽 (포트 22 및 10022가 열려 있음)
라우터에 대해 걱정하지 않고 연결을 저장하는 더 쉬운 방법이 있습니까?
답변
와 함께 두 가지 이상의 솔루션이 ssh -R있습니다. 해당 부분을 혼합 한 것 같습니다. 잘못된 것이 조금 더 있습니다.
HostA에서 듣기, 외부로 열린 포트
역방향 SSH 터널 및 URL을 통해 localhost 웹 서버에 액세스 하는이 질문의 거의 중복입니다 . 나는 여기의 주요 문제가 동일하다고 생각하며 다른 질문에 대한 내 대답이 적용되지만 충분하지 않습니다.
귀하의 명령은 다음과 같습니다.
# on HostB
ssh -R 10022:user@HostB:22 user@HostA
차라리 다음과 같아야합니다.
# on HostB
ssh -R :10022:localhost:22 user@HostA
무엇이 수정 되었습니까?
:전에10022, 앞에 아무것도 빈을 정의한다bind_address. 이것이 없으면 HostA의 SSH 서버localhost:10022는 외부에서 액세스 할 수없는 HostA 의 루프백 인터페이스에만 바인딩됩니다 . 비어 있으면bind_address"모든 인터페이스"를 의미합니다. 자세한 내용 은 연결된 질문에 대한 내 대답을 참조 하십시오.원격 전달 대상은 로컬 컴퓨터 (귀하의 경우 HostB)에서 확인됩니다. HostB 자체에서 HostB의 SSH 서버에 도달하려면
localhost충분합니다. 이는 일반적으로 SSH 서버가 루프백 인터페이스에서 수신 대기하기 때문입니다. 호스트 B에 포인트가 잘 작동 수 있지만, 또 다른 주소localhost또는127.0.0.1가장이다 KISS 같은 경우 -able 하나.대상을 지정할 때 사용자를 지정하지 않아야합니다. 내 말
HostB은 목표물이 작동하지만user@HostB. 귀하의 경우에는 누군가가 실제로 터널을 사용할 때만 주소가 확인되기 때문에 후자 가 작동하는 것처럼 보였습니다 . 터널을 사용한 적이 없습니다. 그렇게했다면ssh프로세스 (-RHostB 에서를 사용하는 프로세스 )는 다음을 생성합니다.connect_to user@HostB: unknown host (Name or service not known)이것이 제 Debian 10의 OpenSSH가 말하는 것입니다.
메모:
- 고려 사항
-N또는-N -f옵션 (참조man 1 ssh) 또는autossh. GatewayPorts yesHostA의 SSH 서버 구성에서 올바른 것입니다.- HostB의 정상적인 방화벽은 루프백 인터페이스에 대한 연결을 차단하지 않아야하며 구성이 필요하지 않습니다. TCP 포트
22가 외부 세계에 개방되어 있는지 여부 는 관련이 없습니다 . - HostA의 방화벽은 TCP 포트
10022(물론22또는 SSH 서버가 수신하는 포트)를 열어야 합니다.
그런 다음 인터넷에서 다음과 같이 연결합니다.
# on HostC or wherever
ssh -p 10022 userB@HostA
HostC에 대한 명령이 어떤 방식으로 호스트 B를 지정하지 않는, 참고 하지만, userB 호스트 B에 유효해야 하나는 자격 증명을 사용한다 userB@hostB. 키 기반 인증을 사용하려면 HostC가 키를 보유해야합니다. HostA의 키는 중요하지 않습니다. HostB의 SSH 서버가 HostA:10022. 주소는 HostA에 속하지만 하나는 HostB에서 실행중인 SSH 서버에 도달합니다. 터널 자체는 투명합니다. 터널이 존재한다는 것을 잊고 HostA:10022HostB의 주소로 취급 하고 단순히 ssh구문을 사용할 수 있습니다. 예 : 다음 명령 :
# on HostC or wherever
ssh -p 10022 userB@HostA hostname
hostnameHostB에서 실행 (시도)합니다 .
HostA에서 사용할 수있는 포트 인 HostA에서 수신 대기
당신이 할 경우 :
# on HostB
ssh -R :10022:localhost:22 user@HostA
그러면 HostA의 SSH 서버는 HostA의 루프백 인터페이스를 포함한 모든 인터페이스에서 수신 대기합니다. 시도한 것과 더 유사한 작업을 수행하는 경우 :
# on HostB
ssh -R 10022:localhost:22 user@HostA
( :이전 에는 없습니다 10022) 그러면 서버는 루프백 인터페이스에서만 수신합니다. 어쨌든 다음과 같이 HostA에서 HostB에 연결할 수 있어야합니다.
# on HostA
ssh -p 10022 userB@localhost
userBHostB에서 유효한 곳 입니다. 이것은 다음과 같이 할 수 있음을 의미합니다.
# on HostC or wherever
ssh user@HostA # or any other userA valid on HostA
# now we're on HostA
ssh -p 10022 userB@localhost
또는 한 줄로 :
# on HostC or wherever
ssh -t userA@HostA 'ssh -p 10022 userB@localhost'
첫 번째 방법과의 차이점 :
- 어떤 경우에는
-t명시 적으로 사용해야 합니다. - HostA의 정상적인 방화벽은 루프백 인터페이스에 대한 연결을 차단하지 않아야하며 구성이 필요하지 않습니다. TCP 포트
10022가 외부 세계에 개방되어 있는지 여부 는 관련이 없습니다 . 즉, HostA의 관리자가 아니더라도 방법이 작동 할 수 있습니다. 또한… GatewayPorts(관리자가 아닌 사람이 조정할 수없는 또 다른 사항)은 반드시yes.- HostB에 대한 연결은 HostA에서 이루어집니다. 키 기반 인증을 사용하려면 HostA가 키를 보유해야합니다. 인증 에이전트 연결을 전달하는 개념이 있으므로 HostC가 키를 보유 할 수 있습니다. 또는 HostC에서 HostB 로의 터널을 생성 할 수 있으므로 나중에 HostC는 두 개의 체인 터널을 통해 HostB의 SSH 서버에 도달하고 자체 키를 사용할 수 있습니다. 나는 자세히 설명하지 않을 것입니다.
- HostA에 대한 SSH 액세스 권한이 있어야합니다. HostC에서 연결하려는 사람이 아니라면 이것을 피하는 것이 좋습니다. 첫 번째 방법을 강력히 선호합니다.