1. PAM(Pluggable Authentication Module)

1.1 PAM 개요

PAM(플러그 가능한 인증 모듈)은 Linux/Unix 시스템에서 서비스를 재컴파일하지 않고, 다양한 인증 기술을 시스템 항목 서비스에 접목할 수 있도록 해주는 프레임워크으로 중앙 집중적인 인증 매커니즘을 지원하는 것이다. 게다가 시스템의 기본적인 인증 기법을 제공하여 이것을 사용하면 응용 프로그램 개발자 뿐만 아니라 시스템 관리자들이 인증을 유연성 있게 관리할 수 있도록 도와 준다.

전통적으로 시스템 자원에 대한 접근을 관리하는 프로그램들은 내장된 메커니즘에 의해 사용자 인증 과정을 수행한다. 이러한 방식은 오랫동안 이루어졌지만 이러한 접근 방식은 확장성이 부족하고 매우 복잡하다. 그렇기 때문인지 이러한 인증 매커니즘을 끌어내기 위한 수많은 해킹 시도가 있었다.

Solaris의 방식을 따라서 Unix/Linux 사용자들은 그들만의 PAM을 구현하는 방식을 찾았다.

PAM의 아키텍처는 다음과 같다.

PAM의 기본 원리는 응용 프로그램이 password 파일을 읽어 오는 대신 PAM이 직접 인증을 수행 하도록 하는 것이다. PAM은 시스템 관리자가 원하는 인증 매커니즘이 무엇이든 상관하지 않는다.

여러 사이트에서 선택 받은 인증 매커니즘은 아직도 password 파일이다. 왜 그럴까? 우리가 원하는 것을 해주기 때문이다. 대부분의 사용자는 password 파일이 필요한 것이 무엇인지 이미 알고 있다. 그리고 원하는 작업을 수행하는데 있어 이미 그 기능이 검증되었기 때문일 것이다.

PAM의 인증 절차는 다음과 같다.

1.2 PAM 동작 원리

PAM은 Windows 환경의 DDL(Dynamic Link Library)과 같은 것이다. Library로 프로그램이 어떤 사용자에 대한 인증을 수행하려면 PAM Library가 있는 함수를 호출한다. PAM은 해당 함수의 Library를 제공하여 응용 프로그램이 특정 사용자를 인증하도록 요청할 수 있다.

PAM을 통해 /etc/passwd 파일이나 /etc/shadow 파일을 확인하거나 또는 보다 복잡한 확인 작업을 수행하기도 하는데, 예로는 LDAP 서버에 접속하는 것이다.

확인 작업을 마치고, 인증 여부를 결정하게 되면 "인증됨/인증되지 않음"의 메시지를 자신을 호출한 응용 프로그램에 전송한다.

간단한 확인 작업이라고 했는데, 그 과정이 많아 보일 수가 있다. 여기에 나오는 각 모듈은 크기가 작고 작업 수행 시간이 매우 빠르다. 이것은 매우 놀랍기도 하지만 PAM을 사용하게 된다.

PAM 의 동작은 프로그램의 실행 하자마자 실행되는 보안 설정 파일들의 프로그램들이다.

PAM의 동작 원리는 다음과 같다.

■ 인증이 필요한 프로그램 동작 시 PAM 라이브러리 호출

■ PAM설정 파일을 참조

■ 참조한 파일의 내용을 바탕으로 모듈 동작

■ 프로그램에 동작 결과를 반환하여 인증여부 결정.

1.3 PAM 사용 이점

PAM을 사용하면 사용자 인증을 위한 시스템 항목 서비스(예: ftp, login, telnet, rsh) 사용을 구성할 수 있다. PAM이 제공하는 몇 가지 이점은 다음과 같다.

■ 유연한 구성 정책

■ 응용 프로그램별 인증 정책

■ 기본 인증 방식을 선택할 수 있는 기능

■ 높은 보안 시스템에서 여러 권한 부여를 요구할 수 있는 기능

■ 최종 사용자의 사용 편의성

■ 암호가 여러 인증 서비스에 대해 동일한 경우 암호 재입력 없음

■ 사용자가 여러 명령을 입력할 필요 없이 여러 인증 서비스에 대해 사용자에게 암호를 요구할 수 있는 기능

■ 사용자 인증 서비스에 선택적 옵션을 전달할 수 있는 기능

■ 시스템 항목 서비스를 변경할 필요 없이 사이트별 보안 정책을 구현할 수 있는 기능

1.4 PAM 파일과 위치

1.5 PAM 라이브러리

1.6 PAM 설정하기

우리가 다룰 설정 파일은 /etc/pam.d 디렉토리에 있다. /etc/security 디렉토리에 있는 특정 모듈에 적용되는 설정 파일을 변경하려면 모듈과 함께 있는 문서를 확인해야 한다.

/etc/pam.d 디렉토리에 있는 각각 PAM 설정 파일의 형식은 다음과 같다.

1) module-type

PAM이 어떤 타입의 인증이 사용될 것인가를 지정한다.

2) contol-flag

PAM에서 사용되는 모듈들이 결과에 따라 어떠한 동작을 취해야 하는지를 지시한다.

required/requisite 차이는 required와 requisite 인터페이스 모두 반드시 "성공" 되어야만 PAM을 이용한 인증이 완료되나 보안 및 가용성 측면에서는 분명한 차이가 존재한다. required의 경우 실패를 해도 실패한 지점이나 결과값에 대한 리턴을 하지 않는데, requisite의 경우 실패한 지점과 원인을 리턴하기에 보안 관점에서는 공격자에게 인증이 거부된 원인을 제공하게 되며, 가용성 측면에서는 실패한 원인을 리턴하여 원인 분석을 용이하게 해준다.

3) module-path

PAM에게 어떤 모듈을 사용할 것인지 그리고 그것을 어디서 찾을지를 알려준다.(인증 작업을 수행하는 모듈이 있는 실제 디렉토리 경로를 지정해 준다) 대부분 구성은 로그인 구성 파일의 경우 마찬가지로 모듈의 이름만 가지고 있다. 이와 같은 경우, PAM은 기본 PAM 모듈의 디렉토리(/lib64/security 또는 /lib/security) 모듈을 찾는다.

4) module-arguments

모듈에게 전달되는 인수를 나타낸다. 각각의 모듈들은 각각의 인수를 가지고 있다.

1.7 PAM 사용예시(일반)

첫 번째 라인은 주석으로써 인증과는 무관하게 사용하고 있는 PAM 모듈의 버전을 표기하며, auth interface를 사용하는 2~4번째 라인은 해당 서비스에 대한 인증 시 사용된다.

1) auth  required  pam_securetty.so

pam_securetty.so 모듈의 경우 사용자가 root로 로그인할 경우 /etc/securetty 파일을 확인하여 해당 파일에 리스팅된 터미널에서 로그인을 시도하는 경우 "성공", 기타의 경우 "실패" 값을 리턴한다.

root외 사용자가 로그인을 시도하는 경우 무조건 "성공" 값을 리턴한다. 이 모듈에 대한 테스트의 결과가 "성공"으로 끝나는 경우 다음 auth 라인으로 이동하여 테스트를 진행한다.

2) auth  required  pam_unix.so  nullok

인증 시도 시 /etc/passwd 및 /etc/shadow 파일의 내용을 기반으로 인증 허용여부를 결정한다. 일반적인 password를 통한 인증을 하는 경우, 이 모듈을 사용한다고 보면 된다.

nullok는 password 입력 시 아무것도 입력하지 않는, null password의 입력을 허용한다는 의미로 대부분의 사용자 인증은 이 라인에서 성공/실패 여부가 결정되며 인증이 성공할 경우 다음 auth 라인으로 진행한다.

3) auth  required  pam_nologin.so

위 예제에서의 인증작업의 마지막 단계에 해당하며, /etc/nologin 파일의 유무를 체크하여 /etc/nologin 파일이 존재하게 되면 시스템(서비스)에서는 root를 제외한 모든 사용자의 접속을 차단하게 되므로 해당 파일이 생성된 경우 root 사용자가 아니라면 인증이 실패하게 된다.

4) account  required  pam_unix.so

pam_unix.so 모듈의 경우 account interface 사용 시 사용자의 계정이 활성화/비활성화 되었는지 또는 password 사용기간이 만료되지 않았는지 등을 판별한다.

auth interface 모듈에서 인증이 성공한 경우 account interface에서 계정 사용이 가능한지 여부 등을 확인하는 단계이다.

5) password  required  pam_cracklib.so  retry=3

password 사용기간 만료 등의 이유로 password 변경을 하게 되는 경우 pam_cracklib.so 모듈을 통해 작업이 진행된다.

이 모듈에서는 password 변경 시 정해진 규칙에 따라 취약한 password를 사용하는지, 사전에 등록된 알기 쉬운 단어를 password로 사용하는지 등을 체크하여 취약한 password로의 변경 시도 시 해당 변경 작업을 차단한다.

6) password  required  pam_unix.so  shadow  nullok  use_authtok

PAM을 사용하는 서비스에서 사용자 password를 변경하는 경우 해당되는 내용으로 arguments 중 shadow의 의미는 password 생성/변경 시 shadow password를 사용한다는 것이며, nullok는 null password의 사용을 허용한다는 뜻이다.

7) session  required  pam_unix.so

사용자가 로그인에 성공하면 사용자 이름, 서비스 타입 등을 로그파일(/var/log/secure) 등에 정상적으로 기록했는지 등을 체크한다.

1.8 PAM 사용예시(/etc/pam.d/su)

시스템 내에서 자주 사용하게 되는 su(Switching User) 명령에 대한 설정으로 su 명령의 경우 root에서 타 사용자로 전환 시 별도의 password를 확인하지 않으며, 일반 사용자에서 일반 사용자 또는 일반 사용자에서 root로의 전환 시에만 변경하고자 하는 계정의 password를 확인한다.

1) auth  sufficient  pam_rootok.so

사용자 전환 시 root의 경우 password 없이 인증을 통과 시켜준다는 의미로 이 모듈의 control-flag가 sufficient로 설정되어 있어 root가 su 명령을 실행할 경우 별도의 인증절차 없이 "성공" 값이 리턴되며 같은 인터페이스(auth)의 나머지 모듈들을 더이상 실행되지 않는다.

root가 아니면 "실패" 값을 리턴하나 sufficient의 경우 실패는 무시되기에 다음 라인으로 넘어 가게 된다.

2) auth  include  system-auth

root가 아닌 경우 다음 라인인 이 부분이 실행되며, include flag는 모듈이 아닌 다른 PAM 파일에 대한 결과를 사용한다.

system-auth 파일을 열어보면 auth 인터페이스에서 pam_unix.so 모듈이 사용되는 것을 알 수 있는데, 이 모듈이 사용자로부터 입력 받은 ID/PW를 시스템 내 DB와 비교하여 성공/실패 여부를 리턴하는 인증에 가장 중요한 모듈이다.

3) 기타

su 명령과 관련해서는 기타 인터페이스(account, password, session 등)는 거의 사용되지 않는다.

1.9 PAM 사용예시(/etc/pam.d/system-auth)

다양한 PAM 관련 설정파일 중 가장 핵심이라 할 수 있는 파일로 Redhat 기준으로 6.0 이상 버전의 경우 system-auth와 password-auth 두 파일이 존재하는데, 둘 중 하나만 사용되는 것이 아닌, 타 PAM 관련 파일들마다 참조하는 파일이 다르므로 그때 그때 확인을 해야 한다.

예를 들어, /etc/pam.d/su에서는 인증에 대한 모듈로 system-auth를 참조하며, /etc/pam.d/sshd에서는 인증에 대한 모듈로 password-auth를 참조한다.

1) auth required pam_env.so

pam_env.so 모듈을 사용하여 인증을 확인한다. 성공 시 남은 모듈 확인, 실패 시 남은 모듈을 확인 하지만 접근은 실패(pam_env.so는 설정 파일에서 환경 변수를 불러온다. /etc/environment, /etc/security/pam_env.conf)한다.

2) auth  required  pam_tally2.so deny=4 unlock_time=1800 no_magic_root reset

pam_tally2.so는 로그인 시도 횟수를 세는 모듈로 일정 횟수 이상 실패 시에는 접근을 차단 및 관리해 주는 역할을 담당한다.

deny=4 : 로그인 시도가 4번 실패하면 추가 시도를 차단함.

unlock_time=1800 : 미리 지정한 일정 횟수 이상 로그인에 실패했을 경우 1800초(30분) 동안 계정이 잠김.

no_magic_root reset : 로그인이 성공한 경우 기존 실패 횟수를 0으로 초기화.

3) auth  sufficient  pam_unix.so nullok try_first_pass

pam_unix.so는 입력 받은 password 등을 시스템 내에 DB와 비교하여 결과를 판별하는 역할을 수행하며, nullok는 password를 공백으로 입력하는 것을 허용한다는 뜻이다.

try_first_pass는 이전 단계에서 입력 받은 password가 있으면 그걸 사용해서 테스트를 수행하며, 입력 받은 password가 없을 경우 새롭게 password를 입력 받아 사용한다는 의미다.

이 모듈의 경우 sufficient로 flag가 설정되어 있어 테스트 결과가 "성공"으로 확인되면 다음에 위치한 auth requisite  pam_succeed_if.so, auth  required  pam_deny.so에 대해서는 더이상 테스트를 수행하지 않는다.

4) auth  required  pam_deny.so

pam_deny.so는 테스트 시도에 대해 무조건 "실패" 값을 리턴한다. 즉, auth로 설정된 위 4개 라인에 대해 테스트가 실패할 경우 마지막으로 pam_deny.so에서 인증을 거부하게 된다.

5) auth  requisite  pam_succeed_if.so uid >= 500 quiet

uid가 500 보다 크거나 같으면 인증을 수행하며, quiet는 로그를 남기지 않는다.

6) password  requisite  pam_cracklib.so try_first_pass retry=3 type= minlen=8 lcredit=-1 dcredit=-1 ocredit=-1

pam_cracklib.so는 Dictionary에 등록된 단어를 이용한 password 설정 등을 방지하기 위한 비교 및 검사를 수행할 때 사용(password-auth, system-auth 등에 필수적으로 포함됨)한다.

retry=3 : 새로운 password를 설정할 때 물어 보는 횟수를 지정, 변경하고자 하는 password가 기준에 미달  

           (복잡도, 최소길이 등)할 경우 몇 번의 입력을 추가로 허용할지를 설정.

minlen=8 : password 최소길이를 지정, 글자수와 크레딧(credit) 값이 조합되어 계산됨.

type= : 새로운 password를 입력할 때 화면에 표기되는 문구를 지정, 없으면 기본값.

dcredit=-1 : 숫자가 갖는 기본 크레딧 값을 지정, 기본값은 1이며 -1로 설정된 경우 password에 반드시 

              숫자가 하나 이상 있어야 한다는 의미.

              (ucredit: 대문자, lcredit: 소문자, ocredit: 기타 특수문자)

만약, 크레딧(예, ucredit) 값이 -1이 아닌 2로 지정되었다면 password 최소길이가 8글자로 설정되었을 때 대문자 하나는 2의 값을 갖게됨. 예를 들면 Abcdefg라는 password는 얼핏 보기에 총 길이가 7문자이지만 대문자 A는 2크리딧 값을 갖게 되어, 이 문자열은 8크리딧이 되고 이에 password 최소길이 8글자라는 조건을 충족하게 된다.

1.10 PAM 사용예시(/etc/pam.d/sshd)

SSH 접속을 제한하기 위해 다음과 같이 vi 명령어를 사용하여 다음과 같은 내용을 추가한다.

추가 후 /etc/ssh/sshusers 파일을 생성한 후 SSH 접속을 제한할 사용자를 다음과 같이 입력한다. (파일 경로와 파일명은 임의로 설정)

저장 후 해당 계정으로 SSH 접속을 시도할 경우 "Access denied" 메시지를 출력하며 접속이 불가능하다.

1.11 SSH(Secure Shell)

Secure Shell은 개방형 소스 SSH 제품인 OpenSSH 제품을 기반으로 한다.(http://www.openssh.org)

Secure Shell은 비보안 네트워크에서 클라이언트와 원격 호스트 간의 보안 연결을 가능하게 한다. 

이 보안 연결의 주요 속성은 다음과 같다.

-클라이언트와 원격 호스트 둘 다에 대한 강력한 인증

-클라이언트와 원격 호스트 간의 통신에 대한 강력한 암호화 및 공개 키 암호화

-클라이언트와 원격 호스트에서 명령을 실행하는데 사용할 보안 연결

Secure Shell은 telnet, remsh, rlogin, ftp, 및 rcp와 같은 자주 사용하는 함수와 명령의 보안 대체 항목을 제공한다.

1) Secure Shell의 주요 보안 기능

Secure Shell의 주요 보안 기능은 다음과 같다.

① 강력한 암호화

클라이언트와 원격 호스트 간의 모든 통신은 Blowfish, 3DES, AES 및 arcfour와 같은 특허 없는 암호화 알고리즘을 사용하여 암호화된다. 암호 등의 인증 정보는 네트워크에서 일반 텍스트로 전송되지 않는다. 또한 암호화는 강력한 공개 키 기반 암호화와 더불어 잠재적 보안 공격을 차단한다.

② 강력한 인증

Secure shell은 클라이언트와 서버 간의 강력한 인증 방법 집합을 지원한다. 인증은 양방향일 수 있다. 서버는 클라이언트를 인증하고 클라이언트도 서버를 인증한다. 이렇게 하면 다양한 보안 문제로부터 세션을 보호할 수 있다.

③ 포트 전달

클라이언트와 원격 호스트 간의 TCP/IP 연결 리디렉션(및 그 반대)을 포트 전달 또는 SSH 터널링이라고 한다. Secure Shell은 포트 전달을 지원한다. 예를 들어, 포트 전달을 사용하여 클라이언트와 서버 간의 ftp 트래픽(또는 전자 메일 클라이언트와 POP/IMAP 서버 간의 전자 메일 트래픽)을 리디렉션할 수 있다. 클라이언트가 직접 서버와 통신하는 대신 보안 채널을 통해 트래픽을 sshd 서버로 리디렉션할 수 있으며, 그런 다음 sshd 서버에서 트래픽을 실제 서버 시스템의 지정된 포트로 전달할 수 있다.

2) Secure Shell의 소프트웨어 구성 요소

Secure Shell 소프트웨어는 클라이언트트 및 서버 구성 요소소 집합으로 이루어져 있다.

3) Secure Shell 실행

위 표에서 나열된 Secure Shell 클라이어트를 실행하기 전에 먼저 Secure Shelll 서버 데몬 sshd를 시작한다.

sshd 데몬은 서버 시스템의 /etc/ssh 디렉토리에 있는 sshd_config 파일에서 초기 값을 가져온다.

sshd_config에 있는 가장 중요한 구성 지시어 중 하나는 sshd 데몬에서 지원하는 인증 방법 집합이다.

- ssh 클라이언트 실행

ssh 클라이언트 응용 프로그램은 sshd 서버와의 소켓 연결을 설정한다.

sshd 서버는 자식 sshd 프로세스를 시작한다.

이 자식은 연결 소켓을 상속 받고 선택된 인증 방법을 기반으로 클라이언트를 인증한다.

인증에 성공한 경우에만 성공적으로 보안 클라이어트 세션이 설정된다.

세션이 만들어진 후 모든 후속 통신은 클라이언트와 이 자식 sshd 프로세스 간에 직접 이루어진다.

이제 클라이언트는 서버에서 원격 명령을 실행할 수 있다.

ssh 클라이언트의 명령 요청이 있을 때마다 자식 sshd 프로세스에서 해당 명령을 실행할 Shell 프로세스를 시작한다.

간단히 말해서 실행 중인 ssh 클라이언트-서버 세션은 다음 프로세스로 구성된다.

① sshd 서버에 연결된 모든 클라이언트 시스템에는 현재 이 클라이언트 시스템에서 설정된 각 ssh 연결에 대한 하나의 ssh 클라이언트 프로세스가 있다.

② 서버 시스템에는 하나의 부모 sshd 프로세스와 서버에 연결된 동시 ssh 클라이언트 개수 만큼의 자식 sshd 프로세스가 있다. 서버에 권한 분리가 활성화되어 있으면 서버에서 실행되는 자식 sshd 프로세스의 수가 두 배로 증가한다.

③ ssh 클라이언트에서 명령 실행 요청이 있을 때마다 서버 시스템의 해당 자식 sshd 프로세스는 Shell 프로세스를 시작하고 Linux 파이프를 사용하여 명령 요청을 이 Dhell 프로세스로 전달한다. 이 Shell 프로세스는 Linux 파이프를 사용하여 명령 실행 결과를 자식 sshd 프로세스로 반환하고 명령 실행이 완료되면 종료된다.

- sftp 클라이언트 실행

sftp 클라이언트 응용 프로그램은 sftp 클라이언트 응용 프로그램이 ssh 클라이언트를 시작 하도록 하고 Linux 파이프를 사용하여 이 클리이언트와 통신한다. 그런 다음 ssh 클라이언트는 sshd 서버와의 소켓 연결을 설정한다.

서버 상호 작용의 나머지 부분은 ssh 클라이언트의 경우와 유사하다. 차이점은 원격 명령을 실행한 Shell을 시작하는 대신 자식 sshd 프로세스가 sftp-server 프로세스를 시작한다는 것이다. 이 sftp 세션 중의 모든 후속 통신은 다음 프로세스 간에 발생한다.

① Linux 파이프를 사용하여 클라이언트 시스템에서 sftp 클라이언트와 ssh 클라이언트 간에

② 설정된 연결 소켓을 통해 ssh 클라이언트와 자식 sshd 프로세스 간에

③ Linux 파이프를 사용하여 자식 sshd 프로세스와 sftp 서버 프로세스 간에

- scp 클라이언트 실행

scp 클라이언트의 경우는 sftp 클라이언트 실행과 거의 동일하다. 차이점은 sftp-server 프로세스를 시작하는 대신 자식 sshd 프로세스가 scp 프로세스를 시작한다는 것이다. scp 세션 중의 모든 후속 통신은 다음 프로세스간에 발생한다.

① 클라이언트 시스템에서 scp 클라이언트와 ssh 클라이언트 간에, Linux 파이프 사용

② 설정된 연결 소켓을 통해 ssh 클라이언트와 자식 sshd 프로세스 간에

③ Linux 파이프를 사용하여 자식 sshd 프로세스와 scp 서버 프로세스 간에

4) Secure Shell 권한 분리

Secure Shell은 권한 분리 기능을 통해 보다 향상된 수준의 보안을 제공한다. 부모 sshd 및 자식 sshd 프로세스는 권한이 부여된 사용자로 실행된다. 권한 분리를 활성화하면 사용자 연결당 하나의 추가 프로세스가 시작된다.

ssh 클라이언트가 권한 분리에 대해 구성된 sshd 서버에 연결하면 부모 sshd 프로세스가 권한이 부여된 자식 sshd 프로세스를 시작한다. 권한 분리를 활설화하면 자식 sshd 프로세스는 권한이 없는 자식 sshd 프로세스를 추가로 시작한다. 권한이 없는 자식 sshd 프로세스는 연결 소켓을 상속 받는다. 클라이언트와 서버 간의 모든 후속 통신은 권한이 없는 이 자식 sshd 프로세스를 사용하여 이루어진다.

클라이언트의 원격 명령 실행 요청은 대부분 비권한이며 권한이 없는 이 자식 sshd 프로세스에서 시작된 Shell에 의해 처리된다. 권한이 없는 자식 sshd 프로세스에서 권한이 부여된 기능을 실행해야 하는 경우 Linux 파이프를 사용하여 권한이 부여된 부모 sshd 프로세스와 통신한다.

권한 분리는 침입자에 의한 잠재적 손상을 제한하는데 도움이 된다. 예를 들어, Shell 명령을 실행하는 동안 버퍼 오버플로 공격이 발생할 경우 권한이 없는 프로세스 내에서 제어되므로 잠재적 보안 위험이 제한된다.

권한 분리는 Secure Shell의 기본 구성이다. sshd_config 파일에서 "UsePrivilegeSeparation NO"를 설정하여 권한 분리를 해제할 수 있다. 잠재적 권안 위험이 있으므로 권한 분리를 해제할 경우 신중하게 고려해야 한다.

5) Secure shell 인증

Secure Shell은 다음 인증 방법을 지원한다.

-GSS-API(Kerberos 기반 클라이언트 인증)

-공개 키 인증

-호스트 기반 인증

-암호 인증

클라이언트는 원격 sshd 데몬과 연결될 때 원하는 인증 방법(앞에 나열된 방법 중 하나)을 선택하고 연결 요청의 일부로 적절한 자격 증명을 제공하거나 서버에서 보낸 프롬프트에 응답한다. 모든 인증 방법이 이런 방식으로 작동한다.

서버가 성공적으로 연결을 설정하려면 클라이언트로부터 적절한 키. 암호구, 암호 또는 자격 증명을 받아야 한다.

sshd 인스턴스에서 보안 요구 사항을 기반으로 지원되는 인증 방법 중 일부만 지원하도록 선택할 수 있다.

Secure Shell은 앞에 나열된 인증 방법을 지원하지만 시스템 관리자가 환경의 특정 보안 요구 사항을 기반으로 sshd 인스턴스에서 제공되는 인증 방법을 제한할 수 있다. 예를 들어, Secure Shell 환경에서 모든 클라이언트가 공개 키 또는 Kerberos 방법을 사용하여 인증해야 한다고 지정할 수 있으며, 이로 인해 나머지 방법은 비활성화될 수 있다. 지원되는 인증 방법 활성화 및 비활성화는 sshd_config 파일에 지정된 구성 지시어를 통해 이루어진다.

ssh 클라이언트 연결 요청이 있으면 서버는 먼저 지원되는 인증 방법 목록으로 응답한다. 이 목록은 sshd 서버에서 지원하는 인증 방법과 이러한 방법이 시도되는 시퀀스를 나타낸다. 클라이언트는 이러한 인증 방법을 하나 이상 생략할 수 있다. 클라이언트에서 방법이 시도되는 시퀀스를 변경할 수도 있다. 이렇게 하려면 클라이언트 구성 파일 /etc/ssh/ssh_config의 구성 지시어를 사용한다.

Secure Shell에서 지원하는 인증 방법은 다음과 같이 요약되어 있다.

① GSS-API(Kerberos 기반 클라이언트 인증)

Kerberos 기반 클라이언트 인증인 GSS-API(Generic Security Sservice application Programming Interface)를 사용하는 경우 클라이언트가 미리 Kerberos 자격 증명을 받아야 하며, 해당 클라이언트 디렉토리에 Kerberos 구성 파일이 있어야 한다.

클라이언트는 sshd 데몬과 연결될 대 연결 시 자격 증명을 제공한다.

서버는 이러한 자격 증명을 이 특정 사용자의 자격 증명 복사본과 일치 시킨다.

또한 선택적으로 클라이언트 호스트 환경의 타당성을 설정할 수 있다.

② 공개 키 인증

공개 키 인증을 사용하려면 Secure Shell 환경에 다음 설정이 있어야 한다..

클라이언트와 서버 둘 다에 키 쌍이 있어야 한다. 모든 ssh 클라이언트와 모든 sshd 서버가 ssh-keygen 유틸리티를 사용하여 자체적으로 키 쌍을 생성해야 한다.

클라이언트는 통신해야 하는 모든 sshd 서버에 해당 공개 키를 알려야 한다. 이렇게 하려면 각 클라이언트의 공개 키를 모든 관련 서버의 미리 지정된 디렉토리에 복사한다.

클라이언트는 통신해야 하는 모든 서버의 공개 키를 구해야 한다. 클라이언트는 ssh-keyscan 유틸리티를 사용하여 공개 키를 받는다.

이 설정이 완료 되면 sshd 서버에 연결하는 ssh 클라이언트가 공개 키와 개인 키를 사용하여 인증된다.

Secure Shell은 공개 키 인증을 단순화하는 추가 기능을 제공한다. 일부 환경에서는 항상 암호 프롬프트에 응답할 필요가 없도록 설정할 수 있다. 둘 다 클라이언트 시스템에서 실행되는 ssh-agent 및 ssh-add 프로세스를 조합해서 사용하면 암호에 응답하지 않아도 된다. 클라이언트는 ssh-add 유틸리티를 통해 ssh-agent 프로세스에 모든 키 정보를 등록한다. 그런 다음 클라이언트와 서버 간의 공개 키 인증은 sshd 데몬이 클라이언트와 상호 작용할 필요 없이 ssh-agent에 의해 수행된다.

③ 호스트 기반 및 공개 키 인증

호스트 기반 및 공개 키 인증은 보다 안전한 공개 키 인증 방법의 확장이다.

클라이언트와 서버 둘 다의 키 쌍이 있는 것 외에도 이 방법을 사용하면 클라이언트 환경에서 통신할 서버를 제한할 수 있다.

클라이언트의 홈 디렉토리에 .rhosts 파일을 만들어 이 제한을 구현한다.

④ 암호 인증

암호 인증 방법은 단일 사용자-ID 및 암호 기반 로그인을 사용한다. 이 로그인은 /etc/passwd에 지정된 사용자 로그인을 기반으로 하거나 PAM 기반일 수 있다.

Secure Shell은 서버 시스템에서 사용할 수 있는 PAM 모듈과 완전히 통합된다. 이목적을 위해 /etc/ssh/sshd_config 파일에 UsePAM 구성 지시어가 있다. YES로 설정하면 클라이언트에서 암호 인증 요청이 있을 때마다 sshd는 PAM 구성 파일(/etc/pam.conf)을 확인한다. 그런 다음 구성된 PAM  모듈을 통해 암호 인증이 성공할 때까지 순서대로 수행한다.

PAM 인증을 무시하려면 UsePAM 지시어를 NO로 설정한다. 그러면 클라이언트에서 암호 인증 요청이 있을 때문다 sshd가 서버의 PAM 구성 설정을 무시한다. 대신 sshd는 gwtpwnam() 라이브러리 호출을 직접 호출하여 사용자 암호 정보를 가져온다.

Secure Shell은 PAM_UNIX, PAM_LDAP 및 PAM_KERBEROS를 사용하여 테스트 되었다. 또한 PAM_DCE 및 PAM_NTLM과 같은 다른 PAM 모듈에서 작동한다.

6) 통신 프로토콜

Secure Shell 사용자는 SSH-1 또는 SSH-2 프로토콜을 사용하여 원격 sshd 데몬과 연결할 수 있다. SSH-2가 더 안전하므로 SSH-1 대신 권장한다.

7) Secure Shell에서 사용하는 기능의 일부 목록

Secure Shell은 실제로 Shell이 아니라 호스트에서 인전하게 원격 shell 세션을 실행하기 위해 클라이언트와 원격 호스트 간에 보안 연결을 만드는 매커니즘이다. 보안 연결을 설정하기 위해 Secure Shell에서 인증과 세션 생성을 대부분 수행한다. Secure Shell에서 사용하는 기능의 일부 목록은 다음과 같다.

① login 시도 기록

telnet 또는 remsh와 마찬가지로 Secure Shell은 성공한 세션과 실패한 세션을 각각 /var/log/wtmp 및 /var/log/btmp 파일에 기록한다.

② PAM 모듈

Secure Shell은 클라이언트 세션에 대해 PAM 인증을 사용할 수 있다. PAM 인증을 선택하면 Secure Shell은 /etc/pam.conf 파일을 사용하고 인증을 위해 해당 PAM 모듈을 호출한다.

③ /etc/default/security 파일 사용

로그인 동작 암호 및 기타 보안 구성을 정의하는 속성이 들어 있는 시스템 범위 구성 파일이다. 몇 가지 제한은 있지만 Secure Shell에서 이러한 속성을 사용할 수 있다.

④ Shadow passwd

Secure Shell은 Shadow passwd 기능과 통합된다.

⑤ 컨트롤 시스템 로그(syslog)

Secure Shell은 syslog를 사용하여 중요한 메시지를 남긴다.

⑥ 감사 로깅

Secure shell은 해당 코드로 감사 로깅(트러스트된 모드)을 구현했다.

8) 비밀번호 없이 SSH에 접속하는 방법

SSH 접속 시 비밀번호 없이 접속하는 방법은 다음과 같다.

① ssh key 생성 (없는 경우만)

② 서버로 로컬에서 만든 공개키 복사

③ 서버 접속 (일반접속)

④ 로그인 후 개인폴더에 .ssh 폴더 생성 (있으면 pass)

⑤ .ssh폴더 권한 변경

⑥ 공개키 인증키 목록에 추가

⑦ 필요없는 공개키 제거

⑧ 인증키 목록 권한 수정

⑨ 서버 접속

1.12 PAM 프로그래밍

아래 소스 코드는 PAM 모듈의 기본 형태로 "#if 0"으로 막혀 있는 부분에 통제를 할 수 있는 코드를 넣어 두면 원하는 동작(차단 또는 허용, 로그 기록)을 쉽게 처리할 수 있다.

위에 있는 pam_sm_...으로 된 함수들이 사용자가 임으로 추가한 함수가 아니라 PAM에서 기본 함수들로서 해당 함수 부분에 원하는 동작 코드를 넣도록 되어 있다.

PAM 모듈 자체가 기존에 동작하는 telnet이나, ssh, login 등의 바이너리에 동적 라이브러리 형태로 붙기 때문에 위 코드에 삽입한 코드들은 로그인과 동시에 해당 서버로의 접속자의 모든 상황들을 감시하고 제어할 수 있다.

1.13 PAM 컴파일 방법

PAM 인증 모듈은 Linux의 특성별 OS에서 제공하는 최적화 옵션에 따라 컴파일 하는 방법은 다음과 같다.

PAM 프로그램 컴파일할 때 반드시 sudo 명령어를 사용하여 컴파일 해야 한다. 그렇지 않으면 다음과 같은 오류가 발생한다.

sudo 명령어는 유닉스 및 유닉스 계열 운영 체제에서 다른 사용자의 보안권한과 관련된 프로그램을 구동할 수 있게 해주는 프로그램이다.

이것은 substitute user do (다른 사용자의 권한으로 명령을 이행하라, 는 뜻이다.) 의 줄임말이다.

기본적으로 Sudo는 사용자 비밀번호를 요구하지만 루트 비밀번호(root password)가 필요할 수 도 있고, 한 터미널에 한번만 입력하고 그 다음부터는 비밀번호가 필요 없다.

Sudo는 각 명령줄에 사용할 수 있으며 일부 상황에서는 관리자 권한을 위한 슈퍼유저 로그인(superuser login)을 완벽히 대신하며, 주로 우분투, 리눅스와 애플의 OS X 에서 볼 수 있다.

PAM을 컴파일하기 위해서는 암복호화 모듈에 "openssl" 라이브러리를 사용하므로 반드시 "openssl"을 다음과 같은 명령어로 설치해야 한다.

1.14 PAM 환경설정

보통 Linux의 경우는 /etc/pam.d/ 디렉토리 안에 서비스마다 별도 설정을 해줘야 한다. 단 설정 양식은 아래와 비슷하다.