SSH란? 기본 설명

SSH(Secure Shell)는 네트워크를 통해 원격으로 다른 호스트에 액세스하는 과정을 보호하기 위한 의도로 설계되었다. SSH는 더욱 우수한 인증 기능뿐만 아니라 SCP(Secure Copy), SFTP(Secure File Transfer Protocol), X 세션 전달 및 포트 전달과 같은 기능을 제공하여 네트워크에서 교환되는 데이터를 암호화함으로써 기타 비보안 프로토콜의 보안성을 강화한다. 사용 가능한 암호화 유형은 512비트 암호화에서 Blowfish, Triple DES, CAST-128, AES(Advanced Encryption Scheme) 및 ARCFOUR와 같은 암호를 포함한 32768비트 암호화에 이르기까지 다양하다. 암호화 비트를 높여서 구성할수록 네트워크 대역폭을 더 많이 사용하게 되는 부작용이 생긴다. 그림 1과 그림 2에서는 네트워크상에 있는 누군가가 Wireshark와 같은 네트워크 스니핑 애플리케이션을 사용하여 telnet 세션을 쉽게 볼 수 있다는 것을 알 수 있다.

telnet과 같은 안전하지 않은 "일반 텍스트" 프로토콜을 사용하면 네트워크상에 있는 누군가가 비밀번호나 기타 민감한 정보를 훔쳐 볼 수 있다. 그림 1에는 telnet 연결을 통해 원격 호스트에 로그인한 사용자 fsmythe가 표시되어 있다. 사용자 이름(fsmythe)과 비밀번호(r@m$20!0)를 입력하면 불행하고 의심 없는 이 telnet 사용자와 동일한 네트워크에 있는 어떤 사용자라도 이 정보를 볼 수 있다.

그림 2에는 전형적인 SSH 세션에 대한 개요와 동일한 네트워크 세그먼트에 있는 다른 사용자가 암호화된 프로토콜을 어떻게 볼 수 없는지가 표시되어 있다. 주요 Linux® 및 UNIX® 배포판은 기본적으로 설치되는 SSH 패키지 버전(일반적으로 오픈 소스 OpenSSH 패키지)과 함께 제공되므로 소스를 다운로드하여 컴파일하지 않아도 된다. Linux나 UNIX 플랫폼을 사용하고 있지 않은 경우에는 지원과 연습을 위해 많은 사용자들이 애용하는 WinSCP, Putty, FileZilla, TTSSH 및 Cygwin(Windows 운영 체제상에 설치되는 POSIX 소프트웨어)과 같은 다양한 오프 소스 및 무료 SSH 기반 도구를 사용할 수 있다. 이러한 도구는 Windows 플랫폼에서 UNIX나 Linux 형태의 쉘 인터페이스를 제공한다.

어떤 운영 체제를 사용하든지 SSH는 일상적인 평범한 컴퓨팅 작업에 매우 긍정적인 혜택을 제공한다. SSH는 믿을 수 있으며 안전하고 유연할 뿐만 아니라 간단한 설치와 사용 그리고 구성—, 게다가 우수한 기능까지 겸비한다.

위로

SSH 아키텍처

IETF RFC 4251 ~ 4256에는 SSH가 "안전하지 않은 네트워크를 통해 원격 로그인을 하거나 기타 안전한 네트워크 서비스를 이용하는 데 필요한 안전한 쉘 프로토콜"이라고 정의되어 있다. 쉘은 세 가지 기본 요소로 구성된다(그림 3 참조).

• 전송 계층 프로토콜: 이 프로토콜에서는 완전한 전방향 개인정보 보호 정책을 사용한 무결성, 서버 인증 및 개인정보 보호 기능이 제공된다. 이 계층은 선택적 압축 기능을 제공하며 TCP/IP 연결을 거쳐 실행되지만, 다른 신뢰할 수 있는 데이터 스트림상에서 사용될 수도 있다.
• 사용자 인증 프로토콜: 이 프로토콜은 서버에서 클라이언트를 인증하며 전송 계층에서 실행된다.
• 연결 프로토콜: 이 프로토콜은 암호화된 터널을 다수의 논리적 채널로 다중화하며 사용자 인증 프로토콜상에서 실행된다.

전송 계층은 주요 데이터 교환 및 서버 인증을 담당한다. 이 계층에서는 암호화, 무결성 검증 및 압축(선택적) 기능이 설정되며 이 계층은 상위 계층 API로 노출되어 일반 텍스트 패킷을 송수신한다. 사용자 인증 계층에서는 클라이언트용 인증뿐만 아니라 여러 가지 인증 방법이 제공된다. 일반적인 인증 방법으로는 비밀번호, 공개 키, keyboard-interactive, GSSAPI, SecureID 및 PAM이 있다.

연결 계층은 SSH 서비스가 제공되는 채널 요청, 글로벌 요청 및 채널을 정의한다. 하나의 SSH 연결로 각각 양방향으로 데이터를 전송하는 여러 개의 채널을 동시에 호스트할 수 있다. 채널 요청은 서버측 프로세스의 종료 코드와 같은 정보를 릴레이한다. SSH 클라이언트는 요청을 시작하여 서버측 포트로 전달한다.

이러한 오픈 아키텍처 설계는 폭넓은 유연성을 제공한다. 전송 계층은 TLS(Transport Layer Security)와 거의 비슷하며 개발자는 사용자 정의 인증 방법을 사용하여 사용자 인증 계층을 확장할 수 있다. 연결 계층을 통해 보조 세션을 단일 SSH 연결로 다중화할 수 있다(그림 4 참조).

위로

UNIX 및 Linux 시스템용 SSH의 일반적인 사용법

일반적으로 SSH를 사용하면 사용자가 원격 호스트에 로그인하여 명령을 실행할 수 있다. 그러나 SSH는 터널링과 X11 연결을 지원한다. 심지어 SFTP나 SCP를 사용하여 파일을 전송할 수도 있다. SSH는 가장 일반적인 플랫폼(예: Linux, UNIX, Windows 및 Apple® OS X)의 다양한 애플리케이션에 적용될 수 있다. 그렇지만 일부 애플리케이션은 특정 SSH 클라이언트나 서버에서만 사용 가능하거나 호환될 수 있는 기능이 필요할 수 있다.

다음에서 몇 가지 일반적인 SSH 구문 예제를 살펴본다.

• 원격 호스트 쉘 액세스(안전하지 않은 프로토콜인 telnet과 rlogin 일반 텍스트를 대체)

  # ssh fsmythe@example.com [fsmythe@example.com] ~

  
  
• 원격 호스트에서 단일 명령 실행(rsh 대체)

  # ssh root@example.com reboot root@example.com's password: ******

  
  
• SCP 명령을 사용하여 로컬 서버에 있는 파일을 원격 호스트로 복사

  root@edb-01.example.com's password: ****** file1.txt 100% 0 0.0KB/s 00:00 file2.txt 100% 0 0.0KB/s 00:00

  
  
• FTP 파일 전송을 대체하는 보안 수단으로 SFTP와 조합

  sftp fsmythe@example.com Connecting to example.com... fsmythe@example.com's password: ******* sftp>

  
  
• rsync와 조합하여 로컬이나 원격 호스트로 파일을 효과적이고 안전하게 백업하고 복사 및 미러링함

  # rsync -avul --rsh=ssh /opt/edbdata/ root@example.com:/root/backup/ root@example.com's password: ****** building file list ... done ./ file1.txt file2.txt file3.txt file4.txt dir1/file5.txt dir2/file6.txt sent 982813 bytes received 2116 bytes 1374860.38 bytes/sec total size is 982138 speedup is 1.00

  
  
• 포트 전달 또는 터널링 포트(VPN과 혼동하지 말 것)

  ssh -L 8000:mailserver:110 example.com fsmythe@example.com's password: ********

  
  
• 원격 호스트에서 X 세션 전달(다수의 중간 호스트를 통해 가능함)

  Edit /etc/ssh/sshd_config and change 2 keywords : AllowTcpForwarding yes X11Forwarding yes # service sshd restart $ export DISPLAY $ ssh -X fsmythe@example.com

  
  
• UNIX나 Linux GUI 서브시스템의 구현을 감안하도록 X11에서 SSH X11 터널링으로 X Windows 클라이언트와 관련된 구성을 전달하면 Linux나 UNIX 원격 호스트를 향하는 SSH 세션의 소스인 동일한 Windows 시스템 호스트에서 안전하게 SSH를 실행할 수 있다.

  ssh -ND 8000 fsmythe@example.com Browser Settings, goto 'Manual Proxy Configuration' set "SOCKS Host" to example.com, the 'Port to 8000' , Enable SOCKS v5, and lastly set 'No Proxy for' field to 'localhost, 127.0.0.1'

  
  
• sshfs를 사용하여 원격 서버에 있는 디렉토리를 로컬 컴퓨터에 있는 파일 시스템으로서 안전하게 마운트

  # yum install sshfs fuse-utils (Install sshfs and fuse-utils) $sshfs example.com:/remote_dir /mnt/local_dir

  
  
• 하나 이상의 메커니즘을 통해 서버를 모니터링하고 관리하는 자동화된 원격 호스트

  (Report number of apache processes running on the remote server example.com): $ ssh example.com ps -ef | grep httpd | wc -l root@example.com's password: *****

  
  

위로

SSH 보안 및 구성 우수 사례

앞서 몇 가지 코드 예제를 설명했지만, 대부분의 우수한 시스템 관리자들이 일부 SSH 보안 구현의 사용과 기능을 신뢰하지 못한다. 일반적으로 SSH 보안과 원격 호스트 보안에 대한 다양한 접근 방식이 많이 언급되었지만, 여기에서는 원격 호스트 액세스와 관련하여 SSH 보안을 강화하는 데 사용할 수 있는 프로세스 및 구성 목록을 다룬다.

• 다음과 같이 루트 계정을 콘솔 액세스 전용으로 제한한다.

  # vi /etc/ssh/sshd_config PermitRootLogin no

  
  
• 개인 키의 강력한 비밀번호 문구와 비밀번호 보호 기능을 사용하여 개인-공개 키 쌍을 작성한다(비밀번호가 없는 키 쌍이나 비밀번호가 없고 비밀번호 문구 키도 없는 로그인은 생성되지 않음).

  (Use a higher bit rate for the encryption for more security) ssh-keygen -t rsa -b 4096

  
  
• 선택된 원격 호스트만 허용하고 원하지 않는 호스트는 거부하도록 TCP 랩퍼를 구성한다.

  # vi /etc/hosts.deny ALL: 192.168.200.09 # IP Address of badguy

  
  
• 워크스테이션이나 랩탑에서는 SSH 서비스를 끈 후 SSH 서버가 사용 불가능해 지면, SSH 서버 패키지를 제거한다.

  # chkconfig sshd off # yum erase openssh-server

  
  
• 사용자 액세스를 제한하여 SSH 액세스를 제한한다.

  # vi /etc/ssh/sshd_config AllowUsers fsmythe bnice swilson DenyUsers jhacker joebadguy jripper

  
  
• SSH Protocol 2만 사용한다.

  # vi /etc/ssh/sshd_config Protocol 2

  
  
• 유휴 세션을 허용하지 않는다. 그리고 유휴 로그아웃 제한시간 간격을 다음과 같이 구성한다.

  # vi /etc/ssh/sshd_config ClientAliveInterval 600 # (Set to 600 seconds = 10 minutes) ClientAliveCountMax 0

  
  
• 호스트 기반 인증을 사용하지 않는다.

  # vi /etc/ssh/sshd_config HostbasedAuthentication no

  
  
• 사용자의 .rhosts 파일을 사용하지 않는다.

  # vi /etc/ssh/sshd_config IgnoreRhosts yes

  
  
• 알려진 네트워크 세그먼트에서만 SSH 연결을 수락하도록 방화벽을 구성한다.

  Update /etc/sysconfig/iptables (Redhat specific file) to accept connection only from 192.168.100.0/24 and 209.64.100.5/27, enter: -A RH-FW-1-INPUT -s 192.168.100.0/24 -m state --state NEW -p tcp --dport 22 -j ACCEPT -A RH-FW-1-INPUT -s 209.64.100.5/27 -m state --state NEW -p tcp --dport 22 -j ACCEPT

  
  
• SSH가 대기하고 바인드될 사용 가능 인터페이스를 제한한다.

  # vi /etc/ssh/sshd_config ListenAddress 192.168.100.17 ListenAddress 209.64.100.15

  
  
• 강력한 비밀번호를 강제로 사용하게 하여 무차별(brute force) 공격과 사회공학 시도 및 사전 공격을 차단하도록 사용자 정책을 설정한다.

  # < /dev/urandom tr -dc A-Za-z0-9_ | head -c8 oP0FNAUt[

  
  
• Chroot SSHD를 사용하여 SFTP 사용자가 자신의 홈 디렉토리만 사용하도록 제한한다.

  # vi /etc/ssh/sshd_config ChrootDirectory /data01/home/%u X11Forwarding no AllowTcpForwarding no

  
  
• 비어 있는 비밀번호를 사용 안함으로 설정한다.

  # vi /etc/ssh/sshd_config PermitEmptyPasswords no

  
  
• 지정된 시간 안에서 수신 포트 2022에 연결되는 연결 수를 제한한다.

  Redhat iptables example (Update /etc/sysconfig/iptables): -A INPUT -i eth0 -p tcp --dport 2022 -m state --state NEW -m limit --limit 3/min --limit-burst 3 -j ACCEPT -A INPUT -i eth0 -p tcp --dport 2022 -m state --state ESTABLISHED -j ACCEPT -A OUTPUT -o eth0 -p tcp --sport 2022 -m state --state ESTABLISHED -j ACCEPT

  
  
• 포트 2022에 연결하려는 시도가 30초 안에 세 번만 허용되도록 iptables를 구성한다.

  Redhat iptables example (Update /etc/sysconfig/iptables): -I INPUT -p tcp --dport 2022 -i eth0 -m state --state NEW -m recent --set -I INPUT -p tcp --dport 2022 -i eth0 -m state --state NEW -m recent --update --seconds 30 --hitcount 3 -j DR

  
  
• 로그를 쉽게 이해하고 로깅 보고서를 작성하기 위해 logcheck, loggrep, splunk 또는 logwatch와 같은 로그 분석기를 사용한다. 또한, SSH 애플리케이션 자체에서 로깅 상세 수준을 늘린다.

  Installation of the logwatch package on Redhat Linux # yum install logwatch

  
  
• SSH 로깅 상세 수준이 증가하도록 구성한다.

  # vi /etc/ssh/sshd_config LogLevel DEBUG

  
  
• 패치 작업을 수행하여 SSH 패키지와 필수 라이브러리를 언제나 최신 상태로 유지한다.

  # yum update openssh-server openssh openssh-clients -y

  
  
• OpenSSH 버전을 감추고 SSH 소스 코드를 요청하여 다시 컴파일한다. 그런 다음, 다음과 같은 업데이트 작업을 수행한다.

  # vi /etc/ssh/sshd_config VerifyReverseMapping yes # Turn on reverse name checking UsePrivilegeSeparation yes # Turn on privilege separation StrictModes yes # Prevent the use of insecure home directory # and key file permissions AllowTcpForwarding no # Turn off , if at all possible X11Forwarding no # Turn off , if at all possible PasswordAuthentication no # Specifies whether password authentication is # allowed. The default is yes. Users must have # another authentication method available .

  
  
• 시스템에서 rlogin과 rsh 2진 파일을 삭제하고 SSH를 가리키는 기호 링크로 바꾼다.

  # find /usr -name rsh /usr/bin/rsh # rm -f /usr/bin/rsh # ln -s /usr/bin/ssh /usr/bin/rsh

  
  

SSH는 사용하거나 사용하지 않을 수 있는 다양한 인증 기술과 방법을 많이 지원한다. /etc/ssh/sshd_config 파일 안에 인증 방법으로 나열된 키워드 다음에 yes나 no를 입력하여 이러한 구성을 변경한다. 여기에서는 일반적인 구성 변경사항 중 일부만 살펴본다.

# RSAAuthentication yes		
# PubkeyAuthentication yes		
# RhostsRSAAuthentication no
# HostbasedAuthentication no
# RhostsRSAAuthentication and HostbasedAuthentication
PasswordAuthentication yes
ChallengeResponseAuthentication no
# KerberosAuthentication no
GSSAPIAuthentication yes

sshd_config 파일 안에 있는 AllowedAuthentications 및 RequiredAuthentications 키워드는 SSH Protocol 2와 함께 사용되는 인증 방법과 구성을 지정하며 비밀번호와 공개 키 인증을 허용하는 해당 구문은 다음과 같다.

# vi /etc/ssh/sshd_config
AllowedAuthentications publickey, password
RequiredAuthentications publickey, password

위로

SSH의 개인 키 및 공개 키 쌍

신원의 유효성을 쉽게 검증할 수 있도록 SSH에는 키 관리 기능과 관련 에이전트가 있다. 공개 키 인증으로 구성된 경우에는 키를 사용하여 원격 SSH 호스트를 대상으로 신원을 입증한다. SSH 기반으로 하는 신원은 두 부분(공개 키와 개인 키)으로 구성된다. SSH 개인 키는 아웃바운드 SSH 연결에 필요한 사용자의 신원이며 비밀로 유지되어야 한다. 사용자가 원격 호스트나 서버로 SSH나 SCP 세션을 시작할 때, 이러한 사용자를 SSH 클라이언트라고 한다. 수학 알고리즘 면에서 개인 키는 전자식 ID 카드와 유사하며 공개 키는 ID 카드를 제시할 잠금 장치나 게이트 메커니즘과 유사하다. 개인 키를 통해 "내가 Fred Smythe이다"라고 전달하면 공개 키는 "당신이 실제로 Fred Smythe이며 이제 인증되었으니 들어가도 좋다"라고 응답한다.

공개 키는 게이트나 잠금 장치를 통해 인바운드 액세스를 허용할 대상자를 나타낸다. 공개 키는 비밀로 유지되어야 한다. 따라서 시스템을 위태롭게 하거나 보증되지 않은 사용자가 시스템에 액세스하는 데 공개 키를 사용해서는 안 된다. Linux나 UNIX 시스템에서는 이러한 개인 키와 공개 키 쌍이 ASCII 텍스트 파일로 저장되지만, Windows 시스템에서는 프로그램 중 일부는 이러한 키 쌍을 텍스트 파일로 저장하고 일부는 Windows 레지스트리에 저장한다.

SSH Protocol 2 구성을 하는 경우에는 다수의 개인 키를 사용하는 다중 ID를 작성할 수 있다. 일반적인 Linux 호스트에서 SSH 개인 키와 공개 키 쌍을 생성하여 설정하고 구성하는 방법을 살펴보자(그림 5 참조).

SSH 개인 및 공개 키 쌍을 구성하는 단계

1단계에 있는 예제(목록 1 참조)에서는 사용자 fsmythe를 대상으로 ssh-keygen 유틸리티를 사용하여 dsa 유형의 SSH 개인-공개 키 쌍을 작성한다.

	
[fsmythe@example.com ~]$ /usr/bin/ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/fsmythe/.ssh/id_dsa):
Enter passphrase (empty for no passphrase): ******    (Enter 'mypassword')
Enter same passphrase again: ******	(Enter 'mypassword')
Your identification has been saved in /home/fsmythe/.ssh/id_dsa.
Your public key has been saved in /home/fsmythe/.ssh/id_dsa.pub.
The key fingerprint is:
33:af:35:cd:58:9c:11:91:0f:4a:0c:3a:d8:1f:0e:e6 fsmythe@example.com
[fsmythe@example.com ~]$

2단계에 있는 예제(목록 2)에서는 이 키 쌍의 개인 키를 소스 호스트에서 대상 호스트의 authorized_keys 파일로 복사하는 과정을 설명한다. 이 파일은 대상 호스트의 원하는 사용자 계정의 홈 디렉토리 아래에 있는 .ssh 서브디렉토리 안에 있다.

	
[fsmythe@example.com ~]$ scp -p /home/fsmythe/.ssh/id_dsa.pub 
fsmythe@thor01.com:/home/fsmythe/.ssh/authorized_keys
fsmythe@ thor01.com's password:
id_dsa.pub       100%  	624   	0.6KB/s    	00:00

3단계의 예제(목록 3)에서는 처음으로 대상 서버를 대상으로 원격 SSH를 호출한다(ls -d /tmp). 그러면 서버의 .ssh/known_hosts에 키가 캐시된다. SSH 개인-공개 키 쌍을 작성했을 때와 같은 비밀번호 문구를 입력하면 원격 대상 서버에서 실행되는 명령의 결과가 소스 서버에서 다시 로컬로 표시된다.

	
[fsmythe@example.com ~]$ ssh root@thor01.com ls -d /tmp
The authenticity of host 'thor01.com (10.12.53.118)' can't be established.
RSA key fingerprint is 84:4f:e5:99:0b:7d:54:d0:1b:3e:2b:96:02:34:41:25.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'thor01.com,10.12.53.118' (RSA) to the list of known hosts.
Enter passphrase for key '/root/.ssh/id_dsa': ******  (Enter 'mypassword') 
/tmp
file1.txt
file2.txt
dir3_5432

참고: 위에 있는 예제에서는 사용자 fsmythe의 비밀번호를 입력할 필요가 없다. 그 대신 첫 번째 단계에서 설정한 비밀번호 문구를 입력해야 한다. 원격 대상 서버를 액세스할 때, 비밀번호 문구를 입력하지 않아도 되는 경우에는 비밀번호 문구를 입력하라는 메시지가 표시될 때, 1단계에서 enter를 입력하여 비어 있는 비밀번호 문구를 작성한다. 그러면, 사용자 fsmythe로 thor01.com 원격 대상 시스템에 액세스할 때 아무것도 입력하지 않아도 된다.

ssh-agent 구성 및 사용

비밀번호가 없는 SSH 공개-개인 키 쌍을 작성하고 싶지 않은 경우에는 ssh-agent 유틸리티를 사용할 수 있다. 간단히 말해서 ssh-agent 유틸리티를 사용하여 현재의 쉘 세션에 대해서만 비밀번호 문구 세트가 존재하는 공개-개인 키 쌍 구성에서 비밀번호가 없는 SSH 액세스를 임시로 승인한다. ssh-agent 유틸리티를 사용하기 전에 다음과 같이 정상적으로 비밀번호 문구를 입력한다.

[root@example01.com ~]# ssh root@example02.com
Enter passphrase for key '/root/.ssh/id_dsa':******	(User must type password)
Last login: Sat May  8 06:37:26 2010 from 10.12.53.118

다음에는 ssh-agent를 쿼리하여 표준 출력에서 Bourne 쉘 명령을 생성한다.

[root@example01.com ~]# ssh-agent -s
SSH_AUTH_SOCK=/tmp/ssh-vxZIxF1845/agent.1845; export SSH_AUTH_SOCK;
SSH_AGENT_PID=1849; export SSH_AGENT_PID;
echo Agent pid 1849;

3단계에서는 현재의 쉘 세션에서 앞서 언급한 환경 변수를 설정한다.

[root@example01 ~]# SSH_AUTH_SOCK=/tmp/ssh-vxZIxF1845/agent.1845;export SSH_AUTH_SOCK
SSH_AGENT_PID=1849; export SSH_AGENT_PID;echo Agent pid 1849
Agent pid 1849

그런 다음, ssh-agent가 실행 중인지 확인한다.

[root@example01.com ~]# ps -fp $SSH_AGENT_PID
UID        PID  PPID  C STIME TTY          TIME CMD
root      1849     1  0 06:14 ?        00:00:00 ssh-agent -s

이제, 실행 중인 ssh-agent 내에서 현재 로드된 신원을 나열한다.

[root@example01.com ~]# ssh-add -l
The agent has no identities.

6단계에서는 원하는 SSH 신원을 추가한다(해당 SSH 키의 올바른 비밀번호 문구를 사용하여 SSH 신원을 사전 인증).

[root@example01.com ~]# ssh-add
Enter passphrase for /root/.ssh/id_dsa:
Identity added: /root/.ssh/id_dsa (/root/.ssh/id_dsa)	****** (Entered 'mypassword')

이제, 이러한 신원이 실행 중인 ssh-agent로 로드되었는지 확인한다.

[root@example01.com ~]# ssh-add -l
1024 33:af:35:cd:58:9c:11:91:0f:4a:0c:3a:d8:1f:0e:e6 /root/.ssh/id_dsa (DSA)

마지막으로 SSH 명령 구문을 사용하여 ssh-agent를 테스트한다. 이제는 비밀번호 문구를 입력하라는 프롬프트가 표시되지 않는다.

# Assuming target remote host has correct authorized key for private key from example01
[root@example01.com ~]# ssh -A root@example02.com	
Last login: Sat May  8 06:36:27 2010 from 10.12.53.118
[root@example02 ~]#

# Assuming target remote host has correct authorized key for private key from example03
[root@example01.com ~]# ssh -A root@example03.com		
Last login: Sat May  8 07:04:05 2010 from 10.12.53.119
[root@example03 ~]#

실제로 개인 키는 사용자가 ssh-add 명령을 사용하여 비밀번호 문구를 입력할 때, 복호화되며 나중에 이 비밀번호 문구로 SSH 연결을 하기 위해 에이전트를 통해 메모리에 배치된다. 개인 키를 다수 입력할 수 있으며 ssh-add 명령을 사용하여 개인 키를 사전에 인증할 수도 있다.

목록 4에 있는 SSH 도구인 ssh-keyscan을 이용하면 다수의 원격 SSH 호스트에서 공용 SSH 호스트 키를 수집할 수 있다. 이 도구는 /etc/ssh_known_hosts 파일을 빌드하는 데 유용하며 특히 빠르고 효과적이다. 주로 자동화를 위한 쉘 스크립트에 적합하다.

	
[root@example01 ~]# /usr/bin/ssh-keyscan -t rsa,dsa example02.com
# example02.comSSH-2.0-OpenSSH_4.3
example02.comssh-dss AAAAB3NzaC1kc3MAAACBALd5/TGn7jCL1DWWzYMw96jw3QOZGBXJgP4m9LACViyM0QHs
ewHGo841JdInfE825mVe0nB/UT15iylLOsI/jFCac+ljQRlO+h2q7WOwGveOUN7TxyKlejM+G1pg5DndGt05iYn+2
dDfn5CmEsI+K0F2vk/+mpoSOk9HKq9VgwNzAAAAFQDPeLAth62TRUcN/nTYoqENBmW3SwAAAIEAryoKa+VaG5LQNj
wBujAuA7hGl+DIWVb1aZ8xAHkcyL5XgrOWEKNnK9mDmEN66oMLfTMO3w8/OvbJUmcXcU3jnL3zguz2E2OIv6t6vAa
F6niL7A/VhxGGxy4CJZnceufStrzZ3UKXRzjwlm0Bwu/LruVF2m3XLvR5XVwUgyWvw+AAAACAaK12k3uC/OOokBgi
eu/SuD5wCSBsf9rqG9ZFa32ujZwRZmA/AwPrZd6q3ASxmjtMp6zGQSzxPczUvLH9D9WIJo713bw8wCPo/7pqiQNRs
OZXqlQyaXyrDout6CI683b1/rxsZKPrJpFNehrZwjWrwpYhK7VaTuzxvWtrDyDxWec=
# example03.comSSH-2.0-OpenSSH_4.3
example03.comssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq5So5VBeH4gPX1A1VEeQkGsb/miiWsWnNTW8ZWYj
2IvU7rKpk/dBIp64WecYYYgDqTK5u0Q+yTijF8wEEI9rRyoh9p5QraM8qy9NxcHzyGqU4vSzfVrblIQrDI8iv7iwz
7PxQAY76NmweaUyGEDfIErty4gCn/ksy85IgffATa9nt36a4iUhiDNifnE8dm1ZrKkvz3lIg0w+Cu0T9MY77AqLWj
Moo0WoQArIvYa0soS3VhzgD/Biwu/sh3eHJtFUxTVxnATdkWkHKUI1wxma3j7jF0saTRKEQSvG6492W+U1FhEjFGN
r7KeZXH99uFpuUWFA7xO7uaG/MLWSjPJMxw==
# example04.comSSH-2.0-OpenSSH_4.3
example04.comssh-dss AAAAB3NzaC1kc3MAAACBALd5/TGn7jCL1DWWzYMw96jw3QOZGBXJgP4m9LACViyM0QHs
ewHGo841JdInfE825mVe0nB/UT15iylLOsI/jFCac+ljQRlO+h2q7WOwGveOUN7TxyKlejM+G1pg5DndGt05iYn+2
dDfn5CmEsI+K0F2vk/+mpoSOk9HKq9VgwNzAAAAFQDPeLAth62TRUcN/nTYoqENBmW3SwAAAIEAryoKa+VaG5LQNj
wBujAuA7hGl+DIWVb1aZ8xAHkcyL5XgrOWEKNnK9mDmEN66oMLfTMO3w8/OvbJUmcXcU3jnL3zguz2E2OIv6t6vAa
F6niL7A/VhxGGxy4CJZnceufStrzZ3UKXRzjwlm0Bwu/LruVF2m3XLvR5XVwUgyWvw+AAAACAaK12k3uC/OOokBgi
eu/SuD5wCSBsf9rqG9ZFa32ujZwRZmA/AwPrZd6q3ASxmjtMp6zGQSzxPczUvLH9D9WIJo713bw8wCPo/7pqiQNRs
OZXqlQyaXyrDout6CI683b1/rxsZKPrJpFNehrZwjWrwpYhK7VaTuzxvWtrDyDxWec=
# example05.comSSH-2.0-OpenSSH_4.3
example05.comssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq5So5VBeH4gPX1A1VEeQkGsb/miiWsWnNTW8ZWYj
2IvU7rKpk/dBIp64WecYYYgDqTK5u0Q+yTijF8wEEI9rRyoh9p5QraM8qy9NxcHzyGqU4vSzfVrblIQrDI8iv7iwz
7PxQAY76NmweaUyGEDfIErty4gCn/ksy85IgffATa9nt36a4iUhiDNifnE8dm1ZrKkvz3lIg0w+Cu0T9MY77AqLWj
Moo0WoQArIvYa0soS3VhzgD/Biwu/sh3eHJtFUxTVxnATdkWkHKUI1wxma3j7jF0saTRKEQSvG6492W+U1FhEjFGN
r7KeZXH99uFpuUWFA7xO7uaG/MLWSjPJMxw==

위로

UNIX 애플리케이션이나 스크립트를 사용하여 SSH 구성

유지보수, 원격 백업 및 기록 시스템용 원격 도구와 원격 쉘 스크립트에서 사용할 목적으로 SSH 액세스를 구성하는 것은 유용하지만, 서버의 보안과 관련해서는 언제나 많은 논란이 있었다. 사용자가 다음과 같이 실행하고자 하는 대부분의 쉘 스크립트는

$ ssh fsmythe@example.com /usr/local/bin/dangerous_script.pl 

인증을 위해 사용자에게 프롬프트되는 필수 SSH 비밀번호 문구를 처리할 수 없다. 그러나 비밀번호 없는 개인-공개 SSH 키 쌍, ssh-agent 구성 또는 신뢰할 수 있는 호스트 네트워크 메커니즘(SSH 비밀번호를 요청하는 프롬프트가 표시되지 않는 메커니즘)이 사전에 구성되어 있지 않는 한, 사실상 이러한 쉘 스크립트는 깨지기 마련이다. 이 때문에 SSH는 해당 쉘 세션과 연관된 현재의 터미널에서 비밀번호 문구를 기대한다. 사용자는 expect 스크립트나 Perl(CPAN Module Net::SSH::Perl 참조) 스크립트를 사용하여 이러한 문제점을 피할 수 있다. (그렇지 않고 쉘 스크립트로 앞서 언급한 유형의 스크립트 중 하나를 호출할 수도 있다.)

#!/usr/local/bin/expect
spawn sftp $argv
expect "password:"
send "mysshpassowrd\r"

일반 사용자가 비밀번호 없는 SSH 메커니즘을 통해 원격 호스트에 액세스할 수 있도록 하는 것은 일부 시스템 관리자의 관점에서는 제재를 받을만하다. 그러나 비밀번호 없는 SSH 메커니즘을 사용하여 원격 호스트에 액세스하는 것을 정당화할 수 있는 다른 보안 수단이 있을 수 있다. 예를 들면, 완전한 bash나 Bourne 쉘 계정 대신 rksh(Restricted Korn Shell) 계정이나 rssh(Restricted Shell) 계정만 주어지는 원격 호스트 시스템 사용자가 이에 해당한다. 또한, authorized_keys 파일로 사용자가 목록에 있는 명령 서브세트만 사용할 수 있게 제한하여 사실상 사용자가 시스템에 피해를 줄 수 있는 명령을 우연히 실행하거나 불필요한 액세스를 하지 않도록 하면서 원격으로 실행하는 데 필요한 정확한 명령만 사용할 수 있게 하는 것도 가능하다. 목록 5에 있는 SSH 액세스 제한 예제에는 이러한 제한 유형이 있다.

	
[fsmythe@example02 .ssh]$ more authorized_keys
command="/usr/local/bin/secureScript.sh",no-port-forwarding,no-X11-forwarding,no-agent-fo
rwarding,no-pty ssh-dss AAAAB3NzaC1kc3MAAACBAOFsC6C7cJUGOZG4Ur9W0J6mxTTk5+MYTu5XfRESPLVwQ
A7HlUxhsXsxgmb1L1RgvR/g0JZnipDS+fGOrN2/IerSpgyzegTVxYLPrOovvuyCn5TA0+rmyrkV27so6yRDkdqTJc
YzWNJOyDndnTrDc/LNmqLFKoGMQ33aur6RNv4VAAAAFQD4leC5Fc1VJqjvXCNsvazBhi84vQAAAIAWbshT80cTESg
dX/srxX4KVNAzY1uhBz5V0UYR4FGP+aoe6laxRj+gQvFIvAKIrpikvBjgyW6cdT8+k0t8HGIQp20MzSBdY9sH8xdj
05AG97Nb/L8xzkceB78qfXhV6txaM1CzssUtiOtaAygrywNPBDEN9MbEbwpVVVyd6iqZNgAAAIAmV0SUZoUr8dHdC
tagRye4bGOQjoztpb4C0RbXQw+w7Jpzr6cZISdZsK4DTBjODvv2+/OWPm7NEzzWyLzHPBNul8hAHOUCOpp+mYWbXX
F78BTk2Ess0SZu8dwpOtasTNEp+xPcsOvQx2Kdr17gTp+28SfpREuLudOr6R3KeTb+hw== fsmythe@example01

이 예제에서는 호스트 example01의 사용자 fsmythe가 ="/usr/local/bin/secureScript.sh 명령만 실행할 수 있다.

위로

SSH를 사용하여 신뢰할 수 있는 호스트 환경 구성

마지막으로, SSH 공용-개인 키 쌍을 설정하는 것에 대한 대안으로 신뢰할 수 있는 호스트 환경을 살펴본다. 자동화를 하는 경우나 이러한 유형의 호출이 필요한 스크립트 환경에서는 여전히 보안과 관련된 위험이 일부 존재하기는 해도 신뢰할 수 있는 호스트 네트워크가 공용-개인 키 쌍 시나리오에 비해 장점이 있다. 신뢰할 수 있는 호스트 네트워크나 신뢰할 수 있는 호스트 인증은 액세스가 허용된 사용자와 호스트 조합이 나열된 사전 구성된 파일에 주로 의존한다. 신뢰할 수 있는 호스트 인증은 두 가지 유형이 있다. 이전의 인증 유형(OpenSSH와 SSH1와 비교하여)과 기능이 부족한 인증 유형에서는 일반 테스트 프로토콜 명령(rsh, rcp 및 rlogin)을 사용하므로 다음 두 파일을 확인하고 sshd_config 파일에서 키워드 하나를 설정한다.

/etc/hosts.equiv
~/.rhosts 

SSH Protocol 2에서는 이 방법이 지원되지 않는다. 그 대신 더욱 안전한 신뢰할 수 있는 호스트 네트워크를 위해 /etc/ssh/sshd_config 파일(호스트 이름이나 IP 주소를 허용)에서 다음을 변경하고 shosts.equiv 및/또는 .shosts 파일을 구성한다.

/etc/shosts.equiv
~/.shosts 

SSH Protocol 2의 /etc/ssh/sshd_config 파일에서 신뢰할 수 있는 호스트 환경을 활성화하려면 다음과 같이 한다.

PermitEmptyPasswords yes
AllowSHosts remoteclient.com
DenySHosts 

예를 들어, 독자가 example.com 서버에 있는 경우에는 /etc/shosts.equiv 파일을 다음과 같이 구성한다.

+remoteclient.com fsmythe
+secureserver.net sallyh
+192.168.100.12 fsmythe
-hackers.org james 

원격 소스 remoteclient.com 및 192.168.100.12에서 액세스하는 사용자 fsmythe와 secureserver.net에서 액세스하는 사용자 sallyh는 액세스가 허용되지만, 원격 소스 hackers.org에서 액세스하는 사용자 james는 액세스가 거부된다.

신뢰할 수 있는 호스트 인증과 공용-개인 키 쌍 인증 방법은 동일한 결과를 얻을 수 있는 우수한 방법이라는 점에서 비슷하다. 표 1에는 이러한 두 가지 인증 방법을 나란히 비교한 결과가 표시되어 있다.

자신의 네트워크에서 비밀번호가 없는 원격 SSH 액세스를 사용하여 신뢰할 수 있는 호스트 인증을 허용한다는 생각을 현재 비웃고 있는 관리자라면 스크립트를 사용하여 원격 SSH 기능을 수행할 때 발생하는 공용-개인 키 쌍의 단점을 생각해 보도록 한다.

• 서버의 호스트 이름이나 IP 주소가 변경되면 캐시되어 있는 알려진 호스트로 인해 공용-개인 키 쌍 구성이 깨진다. .ssh/known_hosts 파일에서 이전의 항목을 제거하고 SSH 원격 호스트 이름 및/또는 IP 주소를 다시 캐시해야 한다. 이렇게 하면 스크립트가 공용-개인 키 쌍에 의존하지 않게 된다.
• 공용-개인 키 쌍 인증 방식은 클라이언트와 서버 구성을 필요로 한다. SSH 공용 키가 변경되거나 키 쌍이 다시 생성되면 모든 원격 호스트의 authorized_keys 파일에서 공용 키를 새로 생성해야 한다.
• .ssh/ 폴더의 사용 권한이나 개인 키 또는 공용 키가 변경되면 SSH 비밀번호 없는 액세스가 불가능하게 된다. 엄격한 파일 및 디렉토리 사용 권한 확인을 사용하지 않으려면 /etc/ssh/sshd_config 파일에서 StrictModes 키워드를 no로 설정한다.
• 일단 키 쌍이 생성되면 키를 취소할 수 있거나 키가 누구에게 배포되었는지 정확히 알 수 있는 중앙화된 방법은 없다.

위로

결론

SSH는 전 세계에 있는 수많은 사용자들이 다양한 태스크를 수행하는 데 사용하는 강력하고 안전한 네트워크 유틸리티이다. SSH는 telnet 및 r* 시리즈 명령과 같은 일반 텍스트 프로토콜에 대한 안전한 대체 수단으로 제공되고 자유롭게 배포 가능한 SSH 클라이언트와 서버로 구성된 다수의 오퍼링이 있는 매우 중요한 도구이다. SSH는 대규모 원격 모니터링, 시스템 유지보수, 원격 시스템 감사, 보고 및 스크립팅 기술 내에서의 자동화를 위해 널리 사용되고 있으며 이는 SSH가 널리 보급되고 계속해서 발전을 거듭할 것이라는 것을 나타낸다.

위로

다운로드 하십시오

다운로드 방식에 대한 정보

참고자료

교육

• SSH(Secure Shell). Wikipedia에는 SSH에 대한 우수한 소개 및 검토 자료가 있다.
  
  
• OpenSSH: OpenSSH는 기술에 익숙한 인터넷 사용자가 주로 사용하는 연결 도구이다. 이 도구는 무료로 사용 가능하다.
  
  
• RFC 4251: SSH 프로토콜 아키텍처를 읽어 보자.
  
  
• The OpenSSH Protocol under the Hood(Girish Venkatachalam, Linux Journal, 2007년 4월): OpenSSH의 "핵심 세부사항"을 확인하자.
  
  
• Server clinic: Connect securely with ssh(Cameron Laird, developerWorks, 2003년 7월): SSH를 사용하여 서버를 보호하는 방법을 자세히 배우자.
  
  
• SSH 및 ssh-agent: Symantec에서 이러한 도구를 자세히 배우고 다운로드하자.
  
  
• SSH 공용 키: 공용 키를 사용하는 데 따른 위험 요인을 자세히 배우자.
  
  
• Linux용 SSH 튜토리얼: Suso.com에는 Linux 환경에서 SSH를 시작하는 데 필요한 우수한 튜토리얼이 있다.
  
  
• Five SSH tricks: 알면 도움이 되는 다섯 가지 SSH 트릭을 확인하자.
  
  
• Top 20 OpenSSH Server Best Security Practices: 이러한 서버 보안 우수 사례를 확인하자.
  
  
• AIX와 UNIX developerWorks 영역: AIX와 UNIX 영역에서는 AIX 시스템 관리와 UNIX 스킬 확장의 모든 측면과 관련된 풍부한 정보를 제공한다.
  
  
• AIX 및 UNIX 입문: AIX와 UNIX 입문 페이지에서 자세한 정보를 볼 수 있다.
  
  
• 기술 서점: 다양한 기술 주제와 관련된 서적을 살펴볼 수 있다.
  
  

토론

• SSH user community: SSH 커뮤니티에 참여하자.
  
  
• Twitter의 developerWorks 페이지를 팔로우하자.
  
  
• developerWorks 블로그: 블로그를 읽어 보고 developerWorks community에 참여하자.
  
  
• My developerWorks 커뮤니티에 참여하자.
  
  
• AIX 및 UNIX® 포럼에 참여하자.
  • AIX Forum
  • AIX Forum for developers
  • Cluster Systems Management
  • Performance Tools Forum
  • Virtualization Forum
  • 기타 AIX and UNIX Forums
  
  

필자소개

아티클 순위

의견

위로

목차

• SSH란? 기본 설명
• SSH 아키텍처
• UNIX 및 Linux 시스템용 SSH의 일반적인 사용법
• SSH 보안 및 구성 우수 사례
• SSH의 개인 키 및 공개 키 쌍
• UNIX 애플리케이션이나 스크립트를 사용하여 SSH 구성
• SSH를 사용하여 신뢰할 수 있는 호스트 환경 구성
• 결론
• 다운로드 하십시오
• 참고자료
• 필자소개
• 의견