By 리차드 실버만, SSH, The Secure Shell: The Definitive Guide 공동 저자
SSH(Secure Shell)는 네트워크로 연결된 컴퓨터간에 안전하면서도 원격 터미널 세션을 제공하는 일련의 통신규약이자 소프트웨어이다. 단순한 원격 명령 프롬프트 외에도 대부분의 SSH 구현은 임의의 TCP 포트에 접속한 것은 물론, X 윈도우 트래픽도 안전하게 포워딩한다. 이러한 특성으로 인해 POP, IMAP, SMTP 같은 비교적 안전하지 않은 통신규약도 보호되는 것이다. SSH 세션은 암호학적 기법을 도입해서 확실하게 사생활을 보호하며 SSH를 통과하는 데이터를 상호 인증한다. SSH는 아주 가치 있는 툴로, 잘만 사용하면 사용자는 오늘날의 인터넷을 좀더 안전하게 서핑할 수 있으며, 시스템 관리자는 네트워크를 보호하며 원격으로 관리할 수 있다.
다양한 특성과 한계를 지닌 여러 운영체제에서 구동된다는 점과 유연성이 좋다는 특성으로 인해 SSH를 접하는 사람들은 많은 질문을 한다. 여기에 자주 등장하는 질문을 모아 놓은 사이트를 링크해 놓았다:
만약 여기를 찾아 봐도 답을 알 수 없다면, 유즈넷 그룹인 comp.security.ssh을 참조하자. 오라일리의
SSH, The Secure Shell: The Definitive Guide를 공동으로 집필하면서, 이 뉴스그룹을 읽는데 시간을 많이 할애했고 직접 몇몇 질문에 답하기도 했다. 여기에 SSH와 관련해서 사용자들이 자주 하는 질문 중 상위 10개를 나열했다. 독자 여러분의 궁금증이 많이 풀리길 바란다.
범례
여기에 사용된 다양한 파일명은 어떻게 프로그램을 불러들이는가에 따라, 혹은 시스템 관리자가 어떻게 SSH를 설정하는가에 따라 설치 방법이 다를 수 있다. 여기에서는 전형적인 디폴트로 설명한다.
SSH 관련 10가지 질문
1) 방금 OpenSSH를 설치했는데, 패스워드 인증이 안됩니다!
패스워드 인증을 위해 현재 유닉스에서 선호하는 것은 “PAM"이다. PAM은 Pluggable Authentication Modules의 머릿글자를 따서 만든 말로, 계정(accounting), 인증(authentication), 권한(authorization)(AAA)을 수행하는 추상적인 프레임워크이다. 이는 특정 AAA 메소드가 아닌 PAM을 이용해 프로그램을 작성할 수 있다는 생각에서 출발한다. 그러면 시스템 관리자는 호스트의 PAM 셋업을 바꿔줌으로써 다양한 프로그램에 AAA를 커스터마이즈할 수 있게 된다. 현재는 셋업을 바꿀 필요 없이, PAM을 재설정하거나 새로운 PAM 모듈을 시스템에 덧붙여서 새로운 AAA 메소드를 사용할 수 있다. 예를 들면 IMAP 서버 데몬은 /var/log/imapd.log에 액션을 로그해서 유닉스 패스워드 맵을 통해 클라이언트를 인증할 수 있다. 데몬 사용자가 패스워드 인증을 위해 PAM을 사용하면, 시스템 관리자는 syslog를 통해 PAM의 액션을 로그하는 대신 PAM을 직접 지시한다. PAM이 있었더라면, IMAP 서버가 이러한 특성을 지원하기 위해 만들어질 필요도 없었을 것이다.
만약 소스로 OpenSSH를 구축하고 있다면,
레드 햇 리눅스를 비롯한 여러 운영체제에서 설정 스크립트가 자동으로 PAM을 실행시킨다. 하지만 설치 과정에서 SSH에 알맞게 호스트의 PAM 설정을 바꿔 주지 않으므로 직접 해야 하며, 이 과정이 끝날 때까지 인증은 되지 않을 것이다. OpenSSH 소스를 배포하는 contrib directory에 가면 여러 운영체제에서 사용 가능한 샘플 PAM 파일이 있다. 다음 명령은 OpenSSH distribution tree 상층에 있으며, 루트로서 실행되는데, 레드 햇에서 작동할 것이다. 이 명령은 샘플 SSH/PAM 설정을 알맞은 장소에 복사한다. PAM을 알게 되면, 이러한 설정 파일을 시험해 보고 자신에게 알맞게 만들고 싶어질 것이다.
# cp contrib/redhat/sshd.pam /etc/pam.d/sshd
# chown root.root /etc/pam.d/sshd
# chmod 644 /etc/pam.d/sshd
|
몇가지 주의할 점:
- SSH PAM파일을 설치한 다음에는 SSH 서버(sshd)를 재실행하지 말 것
- 소스에서 컴파일링해서 설치하는 것보다는 RPM(Red Hat Package Manager) 파일과 같은 이미 컴파일된 패키지의 OpenSSH를 설치하는 것이 더 수월하다. 넷에 돌아다니는 이러한 패키지 중 일부는 sshd를 제어하고 부트할 때 시작하게 만드는 SysV-style “init" 스크립트뿐만 아니라 PAM 파일도 설치해 준다.
Slackware Linux에서는 패스워드를 인증하는 것과 별개의 문제가 발생하기도 한다. 문제가 생기면 다음의 옵션으로 OpenSSH를 만든다. "LIBS=-lcrypt ./configure --md5-passwords"
2) 다른 서버 호스트에 접속할 때는 항상 SSH 명령 행 옵션을 조합해서 사용합니다. 셸 명령 앨리어스를 사용하지 않고 이러한 과정을 자동화할 수 있는 방법이 있습니까?
있다. SSH 클라이언트 설정 파일에서 라벨 섹션(labeled sections)을 이용하면 된다:
# ~/.ssh/config (SSH1 or OpenSSH)
Host foo.bar.com
User slade
PasswordAuthentication no
LocalForward 2143 localhost:143
# ~/.ssh2/ssh2_config (SSH2)
foo.bar.com:
User slade
AllowedAuthentications publickey
LocalForward "2143:localhost:143"
|
이처럼 약간의 수고만 하면 ssh foo.bar.com이라는 명령을 하면 SSH는 다음처럼 인식한다:
ssh -l slade
-L 2143:localhost:143
-o PasswordAuthentication=no
foo.bar.com
|
라벨 섹션(labeled section)은 명령 행의 SSH 호스트 이름과 일치할 때만 사용된다. 만약 자신의 DNS(Domain Name System) 검색 리스트가 bar.com을 포함하고 있고 ssh foo를 입력해서 접속한다면, 위와 같은 설정은 일어나지 않을 것이다.
이 기술은 다른 데에도 사용된다. 이름이 없는 호스트에도 이름을 부여 할 수 있는 것이다:
Host bar
HostName 10.2.3.4
|
혹은 같은 호스트에 다른 닉네임을 사용할 수 있다:
Host foome
HostName foo.bigcorp.com
User me
Host backups
HostName foo.bigcorp.com
User root
Compression yes
CompressionLevel 8
|
이것은 유용한 추상화 메커니즘이다. SSH를 사용하는 스크립트나 프로그램은 실제 호스트이름 대신 이러한 닉네임을 사용할 수 있다. 만약 이처럼 접속하기 위해서 채택한 SSH나 실제 호스트가 바뀌면, 사용자는 SSH 클라이언트 설정 파일만 바꿔 주면된다. 관련된 SSH 명령 전체를 검색해서 바꿀 필요는 없는 것이다.
3) scp를 사용하려고 하면 다른 쪽에서는 “scp: command not found” 라는 문구가 뜹니다.
이러한 상황은 SSH1과, SSH2의 scp2와 대비되는 OpenSSH scp에서 발생하는데, SSH2는 sftp 서버 하부체계를 사용한다. 문제가 되는 것은 기본적으로 scp는 scp라는 원격 카피를 작동시켜 서버 모드에서 대화하면서, scp 하위프로세스에서 SSH를 운용한다는 것이다. scp가 사용하는 명령은 “scp"인데, 이는 scp가 원격으로도 명령 검색 경로에 있어야만 한다는 것을 의미한다. SSH를 설치하면 원격지 PATH 세팅의 디폴트가 적절한 디렉토리가 있지만, sshd가 원격 계정 셸을 사용해서 프로그램을 동작하기 때문에, 원격 사용자나 시스템 셸 시작 파일에 만들어 놓은 모든 PATH 세팅이 이를 무시해 버릴 수 있다(즉 ~/.bashrc, /etc/profile, etc.). 원격지에 PATH 세팅이 실행할 수 있는 scp가 설치된 디렉토리가 있어야 한다.
4) X 포워딩(X forwarding)이 안됩니다!
확인해야 할 사항:
X 포워딩의 특성은 클라이언트와 서버 둘 다에서 실행되어야 한다(ForwardX11를 사용하거나, GUI SSH 클라이언트를 사용할 때는 대화 상자에서 알맞은 상자를 확인한다).
가능하면 단축키를 사용하지 않고 세션을 작동시킨다. 그리고 클라이언트가 X 포워딩을 요구하는지 확실히 해야 하며, 서버가 xauth 프로그램을 찾을 수 없게 되는 등 X 관련 에러를 점검해야 한다.
원격지에서는 DISPLAY 환경 변수(echo $DISPLAY)를 확인한다. 그래서 서버-호스트:1.0과 같은 것이 있어야 한다. sshd는 이것을 프록시 X display에 있는 지점에 설치시킨다. 만약 서버가 OpenSSH이면, XAUTHORITY 환경 변수 또한 확인해야 한다. 이 때에는 /tmp/ssh-rYY10594/cookies 와 같은 것이 있어야 한다. 이러한 변수 중 하나라도 설치돼 있지 않거나 잘못된 값으로 설치돼 있다면, X 포워딩은 되지 않는다. 자신의 사용자나 시스템 셸 시작 파일이 이러한 변수를 리셋하는지를 확인한다. 이와 같은 일은 자주 일어난다.
5) 공개키 인증은 어떻게 합니까?
여기에 확인해야 할 사항들이 있다:
- 공개키 인증이 클라이언트와 서버 측 모두에서 실행되는지 확인한다. 디폴트로 지정돼 있긴 하지만, 완벽을 기하기 위해서 다음에 나오는 설정문을 이용한다:
# SSH1, OpenSSH/1
RSAAuthentication yes
# OpenSSH/2
DSAAuthentication yes
# SSH2
AllowedAuthentications publickey
|
- ssh-kdygen로 키 한 쌍을 생성한다(혹은 사용자의 GUI 클라이언트가 제공하는 것을 사용한다).
- 공개키를 원격 계정의 권한에 둔다.
- SSH1, OpenSSH/1: server:~/.ssh/authorized_keys에 client:~/.ssh/identity.pub 내용을 삽입한다.
- OpenSSH/2: server:~/.ssh/authorized_keys2 에 client:~/.ssh/id_dsa.pub 내용을 삽입한다(마지막에 “2”가 있다는 것을 주지하자).
- SSH2:
- ~/.ssh2/id_dsa_1024_a.pub을 server:~/.ssh2,, say named foo.pub에 복사한다.
- client:~/.ssh2/identification에 IdKey id_dsa_1024_a 줄을 삽입한다.
- server:~/.ssh2/authorization에 Key foo.pub 줄을 삽입한다.
- 우리는 여기서 서버와 클라이언트 양측에서 같은 SSH 구현을 사용하고 있다고 가정한다. 만약 같은 SSH 구현이 아니라면 키 형식을 변환해야 한다. 이 때문에 OpenSSH의 ssh-keygen은 -y, -x, , -X 옵션이 포함돼 있다. 하지만 이는 DSA 키에만 필요하다. RSA 키는 모든 곳에서 같은 형식을 사용하기 때문이다.
- 문장의 맨 끝(end-of-line)을 달리한다는 관습을 조심해야 한다. 예를 들어 Windows/Cygwin에서 OpenSSH로 DSA 키를 생성하려면, ssh-keygen -x를 사용하여 공개키를 SSH2 형식으로 변환하여, 공개키 파일을 유닉스 SSH2 서버 호스트에 복사해서 사용해야 한다. 복사하기에 따라 파일은 행의 한계를 정하는 캐리지 리턴/라인 피드(carriage-return/linefeed)의 결과를 얻을 수도 있는데, 이것이 DOS/Windows의 관습이다. 이때 키는 SSH2에서 작동하지 않는데, SSH2는 하나의 라인피드(a single linefeed)라는 유닉스의 end-of-line 관습을 기대하기 때문이다.
- 원격 계정에 있는 중요한 파일에는 적정한 허가를 설치해 놓는다. 만약 대충 허가해 버린다면 SSH는 공개키 인증을 거절할 것이다. 특히 권한 파일 뿐 아니라, 목표 사용자의 홈과 ~/.ssh(2) 디렉토리는 그룹이나 개인을 떠나서 아무나 쓸 수 있어서는(group-writable, 혹은 world-writable) 안 된다. 예를 들어 SSH1에서는 다음과 같다:
chmod 755 ~ ~/.ssh
chmod 644 ~/.ssh/authorized_keys
chmod 400 {any private key files}
|
물론 원하면 허가를 더욱 어렵게 할 수도 있다. 하지만 SSH 서버 호스트에 있는 홈 디렉토리가 다른 컴퓨터로부터 네트워크 파일 시스템(NFS)을 경유해서 접근한다면, 인증 키 파일은 아무나 읽을 수 있어서는(world-readable) 안 된다. 원격지의 xauth 리스트로 프록시를 나타낼 수 있는 키가 있는지 확인한다.
