한빛출판네트워크

저자:『SSH, The Secure Shell: The Definitive Guide』의 저자 다니엘 J 바렛과 리차드 실버만, 역 이호재

본 기사는 『SSH, The Secure Shell: The Definitive Guide』의 11장을 요약한 기사입니다.

		SSH, The Secure Shell: The Definitive Guide

게이트웨이 호스트를 통한 연결

본 기사에서는 외부로 나가는 모든 연결이 허용된다는 가정 하에 작성된 것입니다. 다시 말해 외부로 나가는 어떠한 TCP 연결도 가능하다는 것을 전제합니다. 물론 여기서 논의하는 방화벽은 오직 들어오는 트래픽만 제한할 것입니다. 좀 더 안전한 환경에서는 이러한 것이 충분하지 않을 수 있으며 실제로 외부로 어떠한 직접적인 연결도 하지 목할 수 있습니다.

지금과 같은 상호 협력의 세상에서 보통 사내에서 외부로 나가는 모든 연결은 프록시(proxy) 서버나 게이트웨이 호스트(회사 네트워크와 바깥 네트워크에 동시에 연결되어 있는 컴퓨터)를 통해서 나가게 됩니다. 게이트웨이 호스트는 비록 양쪽 네트워크에 연결되어 있지만 라우터처럼 동작할 수는 없습니다. 그래서 두 네트워크는 서로 분리되어 있습니다. 오히려 이 게이트웨이 호스트는 두 네트워크 사이에 제한된 애플리케이션 레벨의 접근을 허용합니다.

본 케이스 스터디에서는 이러한 환경에서 발생할 수 있는 SSH에 관련된 사항을 살펴보도록 하겠습니다.

• ssh를 이용하여 외부 호스트에 투명하게 접속하기
• scp 연결하기
• 포트 포워딩을 통해 SSH내에 SSH 실행하기

투명한 SSH 연결

여러분의 회사에 게이트웨이 호스트 G가 있고 오로지 이 게이트웨이 호스트를 통해서만 인터넷에 접근할 수 있다고 가정합시다. [그림 1]에서 보다시피 여러분은 클라이언트 호스트 C에 로그인을 하여 회사 네트워크 밖에 있는 서버 호스트 S에 접근하고자 합니다. 물론 여기에 있는 3개의 머신에는 모두 SSH가 설치되어 있다는 것을 전제로 합니다.

[그림 1] 프록시 게이트웨이

클라이언트 C로부터 서버 S에 접근하기 위해서는 다음과 같은 두 가지 절차가 필요합니다.

1. C에서 게이트웨이 G에 접속하기

   # Execute on client C
   $ ssh G
   

2. G에서 서버 S에 접속하기

   # Execute on gateway G
   $ ssh S
   

물론 위의 방법도 정상적으로 작동하지만 신경쓰지 않아도 되는 서버가 아닌 게이트웨이에서 추가적인 절차를 거쳐야 합니다. 에이전트 포워딩과 공개키 인증을 사용함으로써 게이트웨이 G에 암호(passphrase)를 입력하지 않을 수 있습니다. 굳이 암호를 입력하지 않더라도 추가적인 절차는 이상적으로 투명하게 처리됩니다.

더 나쁜 경우를 예로 들면 클라이언트 C에서 서버 S로 원격 명령을 실행하려고 할 경우 이것은 투명하게 실행할 수 없습니다. 다음과 같은 일반적인 명령어 대신

# Execute on client C
$ ssh S /bin/ls

아래와 같이 게이트웨이 G에서 서버 S로 접속하는 원격 ssh를 실행해야만 합니다.

# Execute on client C
$ ssh G "ssh S /bin/ls"

이것은 귀찮은 작업 일뿐만 아니라 복잡하기 이를데 없는 이상한 자동화가 분명합니다. 이러한 환경에 맞추기 위해 이미 존재하는 SSH 기반의 스크립트를 다시 작성한다고 생각해 보면 이것이 얼마나 이상한 일인지 이해가 갈 것입니다.

다행스럽게도 SSH 설정은 충분히 유연하기 때문에 깔끔한 해결책을 제공합니다. 이를 위해 SSH1의 특징과 문법을 이용할 것입니다. 여기서 우리는 authorized_keys 파일 옵션을 이용하기 위해 공개키 인증을 사용하고, 인증을 두 번째 SSH 접속으로 투명하게 전달하기 위해 에이전트 포워딩 옵션을 사용하는 ssh-agent를 사용할 것입니다([그림 2] 참조).

[그림 2] 프록시 게이트웨이를 통한 연쇄 SSH 연결

여기서 게이트웨이 G에서의 계정을 gilligan으로 서버 S에서의 계정을 skipper라고 가정합시다. 먼저 S라는 이름이 게이트웨이 G의 별명이 될 수 있게 SSH 클라이언트를 다음과 같이 설정합니다.

# ~/.ssh/config on client C
host S
  hostname G
  user gilligan

다음으로 게이트웨이 G에서 서버 S로 SSH 연결을 하기 위해 아래와 같이 명령어를 키와 연결시킵니다.

 # ~/.ssh/authorized_keys on gateway G
command="ssh -l skipper S" ...key..

만약 이러한 설정을 인터랙티브한 연결에서 사용하고 싶다면 ssh에서 -t 옵션을 사용해야 합니다. 이 옵션은 G에 하나의 tty를 할당하게 합니다. 그렇지만 원격 명령어(이 경우엔 또다른 ssh 연결)가 tty를 필요로 하는지 알 수 있는 방법이 없기 때문에 보통 이 옵션을 사용하지 않습니다.

이제 클라이언트 C에서 ssh S 명령어를 실행하면 게이트웨이 G로 접속한 후, 명령어를 자동으로 실행해서 서버 S로 두 번째 SSH 연결을 합니다. 에이전트 포워딩 덕분에 적절한 키를 사용할 경우 자동으로 G에서 S로 인증이 이루어집니다. 이 키는 gilligan@G로 접속할 때 쓰는 키와 같을 수도 있고 다를 수도 있습니다.

이러한 트릭은 클라이언트 C에서 서버 S로의 투명한 접속을 보장할 뿐만 아니라 클라이언트 C에서 S라는 이름을 이해하지 못하는 상황을 피할 수 있도록 해줍니다. 종종 이러한 네트워크 환경에서는 내부 네트워크 이름이 외부와 단절될 수 있습니다(내부 root를 갖는 분리된 DNS 등). 다시 말해 도달할 수 없는 호스트를 사용할 수 있도록 하는 방법이 SSH 클라이언트의 호스트 설정 키워드를 통해서 가능하기 때문입니다. 이는 SSH가 G를 통해 투명하게 외부 호스트에 접근할 수 있도록 별명 S를 생성할 수 있게 합니다.

다니엘 바렛(Daniel J. Barrett)은 모자를 쓰는 것을 좋아합니다. 그 모자들 중 대부분은 바람개비가 달려있는 전동 모자랍니다.

리차드 실버만(Richard Silverman)은 대학교 3학년 때인 1986년에 처음으로 컴퓨터를 접했습니다. 그 당시는 DEC-20에 로그인한 후 메일을 보내기 위해 MM 명령어를 실행해야 했는데 리차드는 DEC-20에 로그인 한 후 컴퓨터 세상에 빠져버렸답니다.