[AIX] ssh 연결 제한

소개

SSH(OpenSSH)에서는 원격 호스트에 대한 보안 암호화 연결 기능을 제공한다. 유효한 AIX® 계정을 가진 사용자라면 SSH를 통해 연결할 수 있다. 하지만, 보안 인식에 관한 시스템에서와 같이, 아마 특정 사용자나 호스트가 SSH를 통해 지정된 시스템에 연결하는 것을 제한해야 한다는 요구사항이 있을 것이다. SSH에서는 거부 및 허용 속성이라는, 사용자 액세스 제한을 위한 두 가지 메커니즘을 제공한다. 이런 키워드는 사용자 및 그룹 목록을 기반으로 한다. TCP 랩퍼를 사용하여 알려진 호스트나 알 수 없는 호스트에서의 SSH 연결을 차단할 수도 있다. 필자는 TCP 랩퍼를 사용하여 호스트 이름/도메인 또는 IP를 기준으로 호스트를 차단하고 사용자/그룹 기반 액세스 제어를 위해 ss hd_config를 사용할 것을 제안한다.

사용자가 설치한 SSH의 종류에 따라 두 곳에서 구성 파일과 SSH 디먼을 찾을 수 있다. 즉, AIX OpenSSH의 경우 구성 파일은 /etc/ssh 파일에 있고 SSH(sshd) 디먼은 /usr/sbin/sshd 파일에 있다.

다른 OpenSSH 유형의 경우, 일반적으로 구성 파일은 /usr/local/etc에 있고 SSH(sshd) 디먼은 /usr/local/sbin/sshd에 있다.

 

TCP 랩퍼로 SSH 제한

TCP 랩퍼는 telnet 또는 FTP 서비스와 같은 inetd에서 시작되는 TCP 기반 애플리케이션을 차단하거나 허용하는 데 사용된다. 일반적으로, SSH는 inetd에서 시작되지 않는다. TCP 랩퍼를 통해 SSH 액세스를 제한하려면 LIBPATH가 가리키는 디렉토리(써드파티 애플리케이션의 경우, 이 디렉토리는 /usr/local/lib일 수 있음)로 libwrap.a를 복사해야 한다. TCP 랩퍼 디먼은 tcpd이다.

/var/adm/messages 파일을 조사해보면 사용자 시스템에 대한 SSH 시도를 찾는 경우가 있을 수 있다. 이런 SSH 시도는 어쩌면 네트워크 내부의 로컬 시스템에서 이루어지는 전적으로 단순한 연결 시도이거나 알 수 없는 호스트에서 이루어지는 무차별 암호 대입 시도일 것이다. 이런 항목들은 더욱 면밀히 조사해야 한다. 이런 SSH 액세스 시도가 불법적인 것이라는 결론을 내리는 경우에는 이런 시도가 차단되어야 한다. sshd_config 파일을 사용하여 호스트를 차단할 수 있겠지만, TCP 랩퍼를 사용하여 호스트를 차단하는 것이 수신 기반 TCP 연결에 대한 1차 방어벽이므로 필자로서는 이 방법을 사용할 것을 제안한다.

TCP 랩퍼(tcpd)는 두 파일을 읽어 수신 TCP 기반 연결의 허용 여부를 결정하는데, 그 두 파일은 다음과 같다.

/etc/hosts.allow /etc/hosts.deny

이들 파일에 대한 변경은 동적으로 이루어진다. 이 두 파일 모두에서 패턴 일치에 대한 규칙에 따라 거부 또는 허용 여부가 제어된다. 이런 규칙은 복잡할 수도, 단순할 수도 있다. hosts.allow가 먼저 검색된다. 패턴 일치를 찾은 경우에는 연결이 허용되는데, 더 정확히 말하자면 tcpd가 종료되면서 실제로 서비스를 제공하는 디먼이 그 역할을 대신하게 된다. 그 다음에 hosts.deny에 대한 패턴 일치 여부가 검색된다. 패턴 일치를 찾은 경우에는 tcpd가 그 연결에 대한 액세스를 거부한다. 간단히 말해, 이는 hosts.allow 규칙이 먼저 적용된 후 hosts.deny 규칙이 적용된다는 뜻이다. 전체적인 규칙은 사용자가 신뢰하는 호스트를 먼저 허용한 후 다른 것은 모두 거부하는 것이다.

이제, TCP 랩퍼가 어떻게 SSH를 통해 호스트에 대한 액세스를 제어할 수 있는지 보여주는 몇 가지 예제를 검토해보자. 우리가 drwho.com이라는 도메인에 속해 있는데, 이 도메인에 속한 사용자만 SSH 액세스를 허용하려 한다고 생각해보자. 다음 메소드로 이를 실현할 수 있다.

# cat hosts.allow sshd : .drwho.com # cat hosts.deny ALL : ALL

이전 예제를 더 구체화하기 위해, 우리는 여전히 drwho.com 도메인 연결은 전부 허용하면서 172.24.11, 172.24.12.(IP 주소의 끝에 있는 점은 그 점 뒤에 있는 모든 것이 일치한다는 뜻임)의 IP 주소 범위도 허용할 수 있다. 다음 예제에서 각 패턴은 쉼표로 구분된다는 점에 주목하자.

# cat hosts.allow sshd: .drwho.com , 172.24.11. , 172.24.12.

일반적으로, 어떤 호스트를 제외한 모든 도메인을 허용하고 싶을 것이다. 프로덕션 시스템인데 개발 시스템에서의 연결을 거부하는 경우가 바로 그런 경우이다. 다음 코드를 통해 이전 예제에서 dev01 및 dev02 호스트 외에 제시되는 모든 호스트를 허용할 수 있다.

# cat hosts.allow sshd: .drwho.com , 172.24.11. , 172.24.12. , EXCEPT dev01, dev02

또한, hosts.allow 또는 hosts.deny 파일에서 username@hostname 형식을 사용할 수도 있다. 예:

dxtans@dev01

정규화된 도메인 이름(FQDN)을 입력해야 할 수도 있다. 이를 테스트하려면 TCP 랩퍼가 메시지 파일에서 호스트 이름을 확인하는 방법을 살펴본 다음, 적절히 hosts.allow 파일을 수정한다.

username@host 형식의 경우, 필자는 sshd_config 파일을 사용하여 액세스를 제어하는 방법을 선호한다. 이렇게 하면 TCP 랩퍼를 사용하여 SSH에 대해서만 사용자/그룹을 인증하기 위한 telnet, FTP 및 ssh_config 파일과 같은 TCP 기반 서비스에 대해서만 호스트를 인증할 수 있기 때문이다. 그러면 시스템 관리자의 관점에서 호스트 및 사용자 액세스 제어를 더 쉽게 관리할 수 있다.

/etc/syslogd.conf에서 /var/adm/messages에 대해 syslog를 통한 연결을 로그에 기록하려면 다음 항목 중 하나가 있어야 한다.

*.info /var/adm/messages

또는

*.auth /var/adm/messages

변경 내용을 적용하려면 syslogd를 다시 시작해야 한다.

# refresh -s syslogd

성공적인 연결에 대해 메시지 파일에 있는 일반적인 항목(이 경우에는 drwho.com이라는 도메인에 속한 tardis라는 호스트의 사용자 dxtans)은 다음과 같은 것이 될 수 있다.

May 25 19:04:46 rs6000 auth|security:info sshd[245928]: Accepted password for dx tans from tardis port 49371 ssh2

hosts.allow 파일에서 적용되는 규칙을 통해 호스트 dev01에서 사용자가 시도했다가 차단된 액세스는 다음과 같은 것일 수 있다.

May 25 19:11:12 rs6000 auth|security:info sshd[270484]: refused connect from dev01

 

sshd_config를 이용한 제한

sshd_config에는 다음 네 항목이 있다.

AllowUsers AllowGroups DenyUsers DenyGroups

이런 키워드가 없으면 필요에 따라 간단히 작성한다. 불안정한 결과가 발생하지 않도록 하기 위해 필요한 키워드만 작성해야 한다. Allow 또는 DenyGroups 유효 그룹만 존재할 수 있기 때문에, 각각의 Allow 또는 DenyUsers 목록은 유효한 사용자 이름으로 공간이 구분된다. 패턴 일치는 DenyUsers,AllowUsers,DenyGroups,AllowGroups의 순서로 되어 있다.

다음과 같이 sshd가 다시 시작될 때까지 sshd_config 파일에 대해 이루어진 어떤 변경 내용도 적용되지 않는다.

# stopsrc -s sshd # startsrc -s sshd

AllowUsers 목록에 사용자 ID를 채우면 해당 사용자만 SSH에 액세스할 수 있다. DenyUsers 목록에도 같은 원리가 적용되어 거부 목록에 들어 있는 사용자만 액세스가 거부된다. 이와 동일한 규칙이 그룹 목록에 적용된다. 이런 규칙들을 몇 가지 혼합하여 적용하면 매우 혼란스러워질 수 있으므로 그렇게 하지 않도록 한다. 보안 요구사항에 따라 허용 목록 또는 거부 목록 중 한 목록만 보유한다.

그 시스템에 대한 계정을 가지고 있지만 AllowUsers 목록에 자신의 사용자 ID가 없는 사용자가 거부 항목이 된다. DenyUsers 목록에 대해서도 같은 규칙이 적용된다. 이제 한 가지 예제를 통해 그 점을 확인해보자. 이때 AllowUsers 목록에 다음이 포함된 것으로 가정한다.

AllowUsers bravo charlie mother oscar delta echoa hotel juliet papa ukflag

사용자 alpha가 SSH 액세스를 시도하는 경우 그 사용자는 사용자 이름이 AllowUsers 목록에 없으므로 액세스가 거부된다.

login as: alpha alpha@rs6000's password: Access denied alpha@rs6000's password: Access denied alpha@rs6000's password:

/var/adm/messages 파일에서 이것을 확인하는 것을 살펴보면, 관리자에게 사용자 alpha가 AllowUsers 목록에 나열되어 있지 않음을 알려준다는 것을 알 수 있다.

Jun 22 18:43:41 rs6000 auth|security:info sshd[270552]: User alpha from tardis not allowed because not listed in AllowUsers Jun 22 18:43:41 rs6000 auth|security:info sshd[270552]: Failed none for invalid user alpha from tardis port 49617 ssh2

이제 DenyUsers 목록을 살펴보고, 목록에 다음이 포함된 것으로 가정하자.

DenyUsers bravo charlie mother oscar delta echoa hotel juliet papa ukflag

시스템에서 계정을 가지고 있고 거부 사용자 목록에 표시되지 않은 모든 사용자가 SSH에 액세스할 수 있다.

사용자 alpha가 SSH에 액세스를 시도하는 경우 그 사용자는 사용자 이름이 DenyUsers 목록에 포함되어 있지 않으므로 액세스가 허용된다. 다음 메시지 파일을 보면 이 사실을 확인할 수 있다.

Jun 22 18:52:48 rs6000 auth|security:info sshd[250040]: Accepted password for alpha from tardis port 49634 ssh2

하지만, DenyUsers 목록에 있는 사용자 bravo가 SSH에 액세스를 시도하면 액세스가 거부된다.

login as: bravo bravo@rs6000's password: Access denied bravo@rs6000's password:

이때도 다음 메시지 파일을 보면 거부 이유를 확인할 수 있다.

Jun 22 18:54:03 rs6000 auth|security:info sshd[245962]: User bravo from tardis not allowed because listed in DenyUsers Jun 22 18:54:03 rs6000 auth|security:info sshd[245962]: Failed none for invalid user bravo from tardis port 49635 ssh2

간단히 생각하자. AllowUsers 목록을 사용하여 받아들일 사용자만 허용하면 된다. 그러면 다른 사용자는 모두 거부될 것이며, 굳이 DenyUsers 목록을 추가할 필요가 없다.

예측할 수 없는 결과를 초래하는 패턴 일치를 중지하려면 반드시 그룹 및 사용자 목록 항목을 가지고 있지 말아야 하지만, 그보다는 사용자 목록 항목(허용 또는 거부) 또는 그룹 목록 항목(허용 또는 거부) 둘 모두가 아니라 그 중 하나만 둔다.

어째서 그게 혼란을 일으킬 수 있는지 살펴보기 위해 다음과 같은 경우를 가정해보자.

AllowUsers alpha DenyUsers bravo charlie mother oscar delta echoa hotel juliet papa ukflag

패턴 일치 순서 때문에, DenyUsers 목록에 포함된 사용자는 그 누구도 액세스 권한이 부여되지 않을 것이며 사용자 alpha에게만 액세스 권한이 부여될 것이라 할 수 있다. 그런 경우에는 AllowUsers 목록만 있어도 된다는 말이다. 해당 사용자 ID가 허용 목록에 표시되어 있지 않으면 거부 목록에 어떤 항목이 포함되어 있더라도 연결을 허용하지 않는다.

그룹에도 같은 원칙이 적용된다. 다음 항목이 있다고 해보자.

AllowGroups water DenyGroups nossh

그룹 water의 구성원은 다음과 같다.

# lsgroup -a users water water users=delta,echoa,golf,plutt

이제, 사용자 dxtans(staff 및 admin 그룹의 구성원)가

# id dxtans uid=203(dxtans) gid=1(staff) groups=205(admin)

연결을 시도하는 경우 사용자 dxtans는 /var/adm/messages의 다음 항목으로 실패하게 된다.

Jun 30 19:50:26 rs6000 auth|security:info sshd[278732]: User dxtans from tardis not allowed because none of user's groups are listed in AllowGroups

왜냐하면 dxtans가 허용 목록에도, 거부 목록에도 없기 때문이다.

SSH 액세스를 허용하지 않으려는 사용자를 포함한 그룹을 작성하면 최소한의 유지 관리 작업만 필요할 것이고, 그런 다음 SSH 액세스가 허용되는 사용자 그룹을 작성하는 것이 유리할 것이다. 예를 들어, SSH 액세스가 허용되지 않는 사용자를 포함한 nossh라는 그룹이 있다고 가정해보자.

# lsgroup -a users nossh nossh users=golf,hotel,india,julie

sshd_config 파일에 다음 항목이 있었다.

DenyGroups nossh

그룹 nossh에 속한 사용자 golf가 SSH 액세스를 시도할 때 메시지 파일에서 볼 수 있는 바와 같이, 그룹 nossh에 속한 어떤 사용자도 액세스가 거부된다.

Jun 22 19:40:36 rs6000 auth|security:info sshd[278778]: User golf from tardis not allowed because a group is listed in DenyGroups

시스템에 많은 수의 사용자가 있을 때는 사용자 목록보다는 그룹 목록을 사용하는 것이 더 유리한 것으로 보일 수 있다.

 

루트 액세스 제어

원격 호스트에서 직접 루트 SSH 액세스를 다룰 때, 필자는 사용자 root로 SSH에 액세스할 수 있는 호스트를 제한하는 것이 최선이라고 생각한다. 관리자는 이런 접근 방식을 통해 사용자 root가 SSH에 액세스할 수 있는 지점을 계속 제어할 수 있으므로, 루트 원격 연결을 계속 제어할 수 있다.

sshd_conf 파일을 통해 사용자 및 호스트에 의한 액세스를 제어하려면 root@<hostname> 또는 root@<hostname.domain>과 같은 형식을 사용할 수 있다.

호스트가 짧은 호스트 이름 또는 긴 호스트 이름 중 어떤 것으로 확인되는지에 상관없이, /var/adm/messages 파일에서 SSH가 보고하는 형식을 볼 필요가 있을 것이다. 이것이 식별되면 해당 항목을 AllowUsers 목록에 간단히 삽입한다. 호스트 이름이 짧은지 긴지 확실하지 않은 경우, 이것은 원래 SSH 연결에서 다른 운영 체제에 따라 좌우될 수 있으므로 짧은 이름과 긴 이름을 모두 포함하는 것이 최선이다.

예를 들어, (drwho 도메인에 속하는) 호스트 tardis에서 루트 액세스만 허용하려면 다음과 같이 할 수 있다.

AllowUsers root@tardis root@tardis.drwho.com

물론, 실제로는 위 목록 역시 다른 사용자들로 채워질 것이다.

배포 서버를 보유하고 있고 (위 예제에서) 그 배포 서버에서 루트 사용자만 결정된 한 호스트에서 모든 클라이언트로 SSH 및 SCP 액세스할 수 있는 경우에 위 방법을 사용하는 것이 이상적이다.

 

사용자 목록 자동 생성

허용 또는 거부 목록이 되도록 사용자 목록을 자동으로 생성할 수 있으면 많은 이점이 있다. 일정 기간 동안 사용자가 추가 및 삭제되므로, 무관심해지거나 목록 업데이트를 잊기 십상일 수 있다. 어떤 목록을 생성해야 할까? 필자는 허용 목록만 채울 것을 제안한다. 그러면 해당 사용자가 AllowUsers 목록에 없는지 여부를 더 쉽게 결정할 수 있다. 목록에 없으면 액세스가 거부된다. AllowUsers 목록으로 사용자를 허용하기 위해 어떤 규칙을 적용하고 있는가? 사용자의 속성에서 사용자가 원격 rlogin/telnet(rlogin=true)을 수행할 수 있는 것으로 나타나면 왜 SSH 액세스도 허용되지 않을까 하는 문제를 고찰해보자. 이 규칙을 즉시 적용하면 모든 시스템 및 애플리케이션 소유자 계정이 삭제되고 정상적인 사용자만 남는다.

일반적인 시스템에서는 모든 시스템 계정 및 애플리케이션 소유자가 일반적으로 로그인할 수 없어야 한다. 따라서 그런 계정에 대한 액세스만 su 또는 sudo를 통해 이루어진다.

그러면 아마 애플리케이션 롤아웃 중에 임시 액세스를 추가로 허용 또는 거부하는 것처럼, 임시 이벤트에 대해서만 목록을 수동으로 편집할 수 있을 것이다. 아래의 목록 1은 이 작업을 수행할 수 있는 한 가지 방법을 나타낸 것이다. 예를 들어, sshd_config 파일의 위치가 먼저 결정되므로, 어떤 SSH 버전을 업데이트할지 알 수 있다. 다음으로, 루트를 제외하고 rlogin 속성이 true인 경우 호스트 상의 모든 사용자 목록이 수집된다. 그 다음으로 /tmp/ssh_ignore 파일이 읽히고 생성된 사용자 목록에서 찾은 일치 항목이 모두 목록에서 삭제된다. 관리자는 ssh_ignore 파일을 사용하여 sshd_config 파일의 허용되는 사용자 목록에 표시되지 않는 사용자에 대해 임시로 변경할 수 있다..

파일 형식은 다음과 같다.

user1 user2 user..

sshd_config 파일의 AllowUsers 목록이 추출된 후 새로 생성된 사용자 목록과 비교된다. 변경 사항이 있는 경우 sshd_config 파일이 업데이트된다. root@tardis의 짧은 이름과 긴 이름이 포함되어 있다는 점에 주목하자. 앞서 설명한 바와 같이, 이는 호스트 tardis의 루트 사용자만 SSH에 액세스할 수 있다는 뜻이고, 따라서 액세스를 적절히 제어할 수 있게 된다. sshd_config에 변경 사항이 있는 경우에는 SSH 서비스가 다시 시작되고 sshd_config AllowUsers 목록의 변경 내용을 관리자에게 알리는 이메일이 발송된다.

이 스크립트에서는 AllowUsers 목록에 대한 항목이 이미 있고 그 목록에 다음과 같이 배포 서버에 대한 항목이 최소한 하나는 들어 있는 것으로 가정한다.

AllowUsers root@tardis root@tardis.drwho.com

즉, 사용자 root만 연결할 수 있는 호스트의 이름이다. 이 예제에서는 호스트 이름에 짧고 긴 호스트 이름이 모두 포함된다(호스트 이름은 tardis임). 자신의 요구에 적합하게 이 스크립트를 수정하고 호스트 tardis를 자신의 호스트로 바꾸면 된다. 하루에 한 번 자주 사용하는 스케줄러에서 이 스크립트를 실행하면 사용자 목록을 최신 상태로 유지할 수 있다.

목록 1. pop_user_allow_ssh

#!/bin/sh #set -x # pop_user_allow_ssh # populate UserAllow entries in sshd_conf # if rlogin is true host=$(hostname) log=/opt/dump/ssh_pop.log >$log if [ -f /usr/local/etc/sshd_config ] then sshd_conf="/usr/local/etc/sshd_config" fi if [ -f /etc/ssh/sshd_config ] then sshd_conf="/etc/ssh/sshd_config" fi echo " on ${host}: ssh config to use: [$sshd_conf]" | tee -a $log # check if we need to run..any user adds/deletes pre=`grep -w ^AllowUsers $sshd_conf` pre=$(echo $pre | sed s/root@tardis.drwho.com//g |sed s/root@tardis//g|sed s/AllowUsers//g) curr=$(lsuser -a rlogin ALL |grep true| grep -v root| awk '{print $1}') # check for ignores - do NOT add to allow list if [ -f /tmp/ssh_ignore ] then cat /tmp/ssh_ignore|while read user do new_curr=$(echo $curr | tr ' ' '\n' | grep -v '^'$user'$' | tr '\n' ' ') echo "[$user]" curr=$new_curr done fi echo "curr [$curr]" echo "pre [$pre]" echo $curr >/tmp/curr.txt echo $pre >/tmp/pre.txt diff /tmp/curr.txt /tmp/pre.txt 2>&1 if [ $? = 0 ] then echo "no user adds/deletes detected on system"| tee -a $log exit 0 else echo "changes detected..re-populating" |tee -a $log fi cp $sshd_conf $sshd_conf.bak sed '/AllowUsers/d' $sshd_conf >$sshd_conf.$$ echo "AllowUsers root@tardis root@tardis.drwho.com" $curr >>$sshd_conf.$$ mv $sshd_conf.$$ $sshd_conf stopsrc -s sshd sleep 2 startsrc -s sshd # next determine change and email out change >/tmp/curr.txt2 >/tmp/pre.txt2 cat /tmp/curr.txt|tr " " "\n" | while read name do echo $name >>/tmp/curr.txt2 done cat /tmp/pre.txt| tr " " "\n" | while read name do echo $name >>/tmp/pre.txt2 done diff /tmp/pre.txt2 /tmp/curr.txt2 >/tmp/allow_diff.txt changelist=$(cat /tmp/allow_diff.txt | egrep "<|>" | sed 's/[<>]//g') list="admins@drwho.com" mail -s "`hostname` allowed users sshd_config change" $list <<mayday Host: `hostname` SSH: $sshd_conf The following users have been either added or deleted in AllowUsers: $changelist mayday

 

디버깅

메시지 파일에 충분한 정보가 표시되어 있지 않은 상황에서 디버깅을 사용하려면 클라이언트 측에서 자세한 정보 표시(v)를 사용하고, v가 많을수록 SSH를 통해 연결할 때 더 세부적인 옵션이 제공된다는 뜻이다.

ssh -vv -l <login> <hostname>

서버 측에서 sshd 서비스를 중지하고 디버그 옵션으로 시작한다. 디버그(d)는 더 자세한 정보가 표시됨을 의미한다. 연결이 되면 sshd가 종료된다. 그런 다음, (추가로 테스트해야 하는 경우) 디버그 모드에서 다시 시작하거나 startsrc 명령을 통해 정상적으로 다시 시작해야 한다. 디버그 모드에서 시작하려면 다음 스크립트를 사용한다.

# /usr/sbin/sshd -dd

SSH를 통해 연결을 시도할 때 문제가 발견되고 그 문제가 바로 명확히 규명되지 않는 경우에는 클라이언트 및 서버 디버그 방법을 함께 사용하여 문제를 진단하는 것이 좋다.

디버그 모드에서 sshd를 시작했을 때의 일반적인 출력은 다음과 같을 수 있다.

# /usr/sbin/sshd -dd debug2: load_server_config: filename /etc/ssh/sshd_config debug2: load_server_config: done config len = 277 debug2: parse_server_config: config /etc/ssh/sshd_config len 277 debug1: sshd version OpenSSH_5.0p1 debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' ….. debug2: parse_server_config: config reprocess config len 277 User bravo from rs6000 not allowed because listed in DenyUsers input_userauth_request: invalid user bravo

sshd가 디버그 모드에서 시작되는 경우, sshd가 sshd_conf에서 찾은 모든 오류가 표준 출력으로 보고된다. startsrc 명령에 의해 sshd가 시작되는 경우, sshd_conf 파일에서 찾은 모든 오류가 /var/adm/messages 파일에 표시된다. 또한, 마지막 존재 상태를 검사하여 다음 메소드를 사용할 수 있다(구성과 관련된 문제가 있는지 결정할 수 있음).

# /usr/sbin/ssh -t # echo $?

하지만, SSH 관련 문제를 진단할 때는 이 디버그 메소드를 사용하는 것이 우선되어야 한다.

 

결론

SSH를 사용하면 원격 호스트에 대해 보안 암호화 연결을 할 수 있다. 하지만, 어떤 수신 연결에서도 그렇듯이, 이런 연결을 정책으로 정의할 필요가 있다. sshd_config에서 TCP 랩퍼와 Allow/Deny 목록을 사용하면 보안에 관해 사전 예방적인 자세를 취할 수 있다.

참고자료

제품 및 기술 얻기

• http://sourceforge.net/projects/openssh-aix/에서 최신 AIX OpenSSH를 다운로드한다.
  
  
• TCP 랩퍼 다운로드

 

출처 : IBM http://www.ibm.com/developerworks/kr/aix/library/au-ssh_restrict/index.html

[출처] [AIX] ssh 연결 제한 |작성자 지성애비