Secure Shell 구성(작업)

Secure Shell은 설치 시에 구성됩니다. 기본값을 변경하려면 관리 개입이 필요합니다. 다음 작업은 일부 기본값을 변경하는 방법을 보여줍니다.

Secure Shell 구성(작업 맵)

다음 작업 맵에서는 Secure Shell 구성 절차에 대해 설명합니다.

Secure Shell에 대한 호스트 기반 인증 설정 방법

다음 절차에서는 서버에서 클라이언트의 개인 키가 인증에 사용되는 공개 키 시스템을 설정합니다. 사용자는 공개/개인 키 쌍을 만들어야 합니다.

절차에서 언급되는 클라이언트와 로컬 호스트라는 용어는 사용자가 ssh 명령을 입력한 시스템을 나타냅니다. 서버와 원격 호스트라는 용어는 클라이언트가 연결하려고 시도 중인 시스템을 나타냅니다.

시작하기 전에

root 역할을 맡아야 합니다. 자세한 내용은 지정된 관리 권한을 사용하는 방법을 참조하십시오.

1. 클라이언트에서 호스트 기반 인증을 사용으로 설정합니다.

   클라이언트 구성 파일 /etc/ssh/ssh_config에서 다음 항목을 입력합니다.

   HostbasedAuthentication yes

   파일 구문은 ssh_config(4) 매뉴얼 페이지를 참조하십시오.

2. 서버에서 호스트 기반 인증을 사용으로 설정합니다.

   서버 구성 파일 /etc/ssh/sshd_config에서 동일한 항목을 입력합니다.

   HostbasedAuthentication yes

   파일 구문은 sshd_config(4) 매뉴얼 페이지를 참조하십시오.

3. 서버에서 클라이언트가 신뢰할 수 있는 호스트로 인식될 수 있도록 하는 파일을 구성합니다.

   자세한 내용은 sshd(1M) 매뉴얼 페이지의 FILES 절을 참조하십시오.

   • 서버의 /etc/ssh/shosts.equiv 파일에 클라이언트를 항목으로 추가합니다.

     client-host

   • 또는 사용자에게 ~/.shosts 파일에 클라이언트에 대한 항목을 추가하도록 할 수도 있습니다.

     client-host

4. 서버에서 sshd 데몬이 신뢰할 수 있는 호스트 목록에 액세스할 수 있는지 확인합니다.

   /etc/ssh/sshd_config 파일에서 IgnoreRhosts를 no로 설정합니다.

   ## sshd_config
   IgnoreRhosts no

5. 사이트의 Secure Shell 사용자에게 두 호스트에 대한 계정이 있는지 확인합니다.
6. 다음 중 하나를 수행하여 서버에서 클라이언트의 공개 키를 삽입합니다.
   • 서버에서 sshd_config 파일을 수정한 다음 사용자에게 ~/.ssh/known_hosts 파일에 클라이언트의 공개 호스트 키를 추가하도록 합니다.

     ## sshd_config
     IgnoreUserKnownHosts no

     사용자 지침은 Secure Shell에서 사용할 공개/개인 키 쌍 생성 방법을 참조하십시오.

   • 서버에 클라이언트의 공개 키를 복사합니다.

     호스트 키는 /etc/ssh 디렉토리에 저장되어 있습니다. 일반적으로 첫번째 부트 시 sshd 데몬이 키를 생성합니다.

     1. 서버에서 /etc/ssh/ssh_known_hosts 파일에 키를 추가합니다.

        클라이언트에서 한 행에 백슬래시 없이 명령을 입력합니다.

        # cat /etc/ssh/ssh_host_dsa_key.pub | ssh RemoteHost \
        'cat >> /etc/ssh/ssh_known_hosts && echo "Host key copied"'

     2. 프롬프트가 표시되면 로그인 암호를 제공합니다.

        파일이 복사되면 "Host key copied" 메시지가 표시됩니다.

        /etc/ssh/ssh_known_hosts 파일의 각 행은 공백으로 구분된 필드로 구성됩니다.

        hostnames algorithm-name publickey comment

     3. /etc/ssh/ssh_known_hosts 파일을 편집하고 복사된 항목에 RemoteHost를 첫번째 필드로 추가합니다.

        ## /etc/ssh/ssh_known_hosts File
        RemoteHost <copied entry>

예 15-1 호스트 기반 인증 설정

다음 예에서는 각 호스트가 서버와 클라이언트로 구성됩니다. 각 호스트의 사용자는 다른 호스트에 대한 ssh 연결을 시작할 수 있습니다. 다음은 각 호스트를 서버와 클라이언트로 만드는 구성입니다.

• 각 호스트에서 Secure Shell 구성 파일에는 다음 항목이 포함되어 있습니다.

  ## /etc/ssh/ssh_config
  HostBasedAuthentication yes
  # 
  ## /etc/ssh/sshd_config
  HostBasedAuthentication yes
  IgnoreRhosts no

• 각 호스트에서 shosts.equiv 파일에는 다른 호스트에 대한 항목이 포함되어 있습니다.

  ## /etc/ssh/shosts.equiv on machine2
  machine1

  ## /etc/ssh/shosts.equiv on machine1
  machine2

• 각 호스트의 공개 키는 다른 호스트의 /etc/ssh/ssh_known_hosts 파일에 있습니다.

  ## /etc/ssh/ssh_known_hosts on machine2
  … machine1

  ## /etc/ssh/ssh_known_hosts on machine1
  … machine2

• 사용자는 다음과 같이 두 호스트에 대한 계정을 가집니다.

  ## /etc/passwd on machine1
  jdoe:x:3111:10:J Doe:/home/jdoe:/bin/sh

  ## /etc/passwd on machine2
  jdoe:x:3111:10:J Doe:/home/jdoe:/bin/sh

Secure Shell에서 포트 전달을 구성하는 방법

포트 전달은 로컬 포트가 원격 호스트로 전달될 수 있도록 합니다. 소켓이 로컬측의 포트를 수신 대기하도록 효과적으로 할당됩니다. 마찬가지로 원격측에서도 포트를 지정할 수 있습니다.

시작하기 전에

root 역할을 맡아야 합니다. 자세한 내용은 지정된 관리 권한을 사용하는 방법을 참조하십시오.

1. 포트 전달을 허용하도록 원격 서버의 Secure Shell 설정을 구성합니다.

   /etc/ssh/sshd_config 파일에서 AllowTcpForwarding의 값을 yes로 변경합니다.

   # Port forwarding
   AllowTcpForwarding yes

2. Secure Shell 서비스를 다시 시작합니다.

   remoteHost# svcadm restart network/ssh:default

   지속 서비스 관리에 대한 자세한 내용은 Oracle Solaris 11.1에서 서비스 및 결함 관리의 1 장, 서비스 관리(개요) 및 svcadm(1M) 매뉴얼 페이지를 참조하십시오.

3. 포트 전달을 사용할 수 있는지 확인합니다.

   remoteHost# /usr/bin/pgrep -lf sshd
    1296 ssh -L 2001:remoteHost:23 remoteHost

Secure Shell 기본값에 대한 사용자 및 호스트 예외를 만드는 방법

이 절차에서는 /etc/ssh/sshd_config 파일의 전역 절 뒤에 조건부 Match 블록을 추가합니다. Match 블록 뒤의 키워드/값 쌍은 일치 항목으로 지정된 사용자, 그룹, 호스트 또는 주소에 대한 예외를 지정합니다.

시작하기 전에

solaris.admin.edit/etc/ssh/sshd_config 권한 부여가 지정된 관리자여야 합니다. 기본적으로 root 역할에는 이 권한 부여가 있습니다. 자세한 내용은 지정된 관리 권한을 사용하는 방법을 참조하십시오.

1. /etc/ssh/sshd_config 파일을 편집합니다.
2. 기본 설정 이외의 다른 Secure Shell 설정을 사용하도록 사용자, 그룹, 호스트 또는 주소를 구성합니다.

   Match 블록을 전역 설정 뒤에 배치합니다.

   ---

   주 - 파일의 전역 절에는 기본 설정이 나열될 수도 있고 나열되지 않을 수도 있습니다. 기본값은 sshd_config(4) 매뉴얼 페이지를 참조하십시오.

   ---

   TCP 전달을 사용할 수 있도록 허용되지 않아야 할 사용자가 있을 수도 있습니다. 다음 예에서는 public 그룹의 사용자 및 이름이 test로 시작하는 사용자가 TCP 전달을 사용할 수 없습니다.

   ## sshd_config file
   ## Global settings
   
   # Example (reflects default settings):
   #
   # Host *
   #   ForwardAgent no
   #   ForwardX11 no
   #   PubkeyAuthentication yes
   #   PasswordAuthentication yes
   #   FallBackToRsh no
   #   UseRsh no
   #   BatchMode no
   #   CheckHostIP yes
   #   StrictHostKeyChecking ask
   #   EscapeChar ~
   Match Group public
    AllowTcpForwarding no
   Match User test*
    AllowTcpForwarding no

   Match 블록 구문에 대한 자세한 내용은 sshd_config(4) 매뉴얼 페이지를 참조하십시오.

sftp 파일에 대한 격리된 디렉토리를 만드는 방법

이 절차에서는 특히 sftp 전송을 위해 만들어진 sftponly 디렉토리를 구성합니다. 사용자는 전송 디렉토리 외부의 파일 또는 디렉토리를 볼 수 없습니다.

시작하기 전에

root 역할을 맡아야 합니다. 자세한 내용은 지정된 관리 권한을 사용하는 방법을 참조하십시오.

1. Secure Shell 서버에서 격리된 디렉토리를 chroot 환경으로 만듭니다.

   # groupadd sftp
   # useradd -m -G sftp -s /bin/false sftponly
   # chown root:root /export/home/sftponly
   # mkdir /export/home/sftponly/WWW
   # chown sftponly:staff /export/home/sftponly/WWW

   이 구성에서 /export/home/sftonly는 root 계정만 액세스할 수 있는 chroot 디렉토리입니다. 사용자에게 sftponly/WWW 하위 디렉토리에 대한 쓰기 권한이 있습니다.

2. 계속해서 서버에서 sftp 그룹에 대한 Match 블록을 구성합니다.

   /etc/ssh/sshd_config 파일에서 sftp subsystem 항목을 찾고 파일을 다음과 같이 수정합니다.

   # pfedit /etc/ssh/sshd_config
   ...
   # sftp subsystem
   #Subsystem       sftp    /usr/lib/ssh/sftp-server
   Subsystem       sftp    internal-sftp
   ...
   ## Match Group for Subsystem
   ## At end of file, to follow all global options
   Match Group sftp
         ChrootDirectory %h
         ForceCommand internal-sftp
         AllowTcpForwarding no

   다음 변수를 사용하여 chroot 경로를 지정할 수 있습니다.

   • %h – 홈 디렉토리를 지정합니다.

   • %u – 인증된 사용자의 사용자 이름을 지정합니다.

   • %% – % 기호를 이스케이프 처리합니다.

3. 클라이언트에서 구성이 올바르게 작동하는지 확인합니다.

   chroot 환경의 파일이 다를 수 있습니다.

   root@client:~# ssh sftponly@server
   This service allows sftp connections only.
   Connection to server closed. No shell access, sftp is enforced.
   root@client:~# sftp sftponly@server
   sftp> pwd sftp access granted
   Remote working directory: /chroot directory looks like root directory
   sftp> ls
   WWW             local.cshrc     local.login     local.profile
   sftp> get local.cshrc
   Fetching /local.cshrc to local.cshrc
   /local.cshrc    100%  166     0.2KB/s   00:00user can read contents
   sftp> put /etc/motd
   Uploading /etc/motd to /motd
   Couldn't get handle: Permission denieduser cannot write to / directory
   sftp> cd WWW
   sftp> put /etc/motd
   Uploading /etc/motd to /WWW/motd
   /etc/motd     100%  118     0.1KB/s   00:00user can write to WWW directory
   sftp> ls -l
   -rw-r--r--    1 101  10    118 Jul 20 09:07 motdsuccessful transfer
   sftp>