SSH 보안 강화, 인증 방법 5가지 총정리

서버를 운영하다 보면 가장 먼저 열게 되는 문이 SSH다. 그만큼 가장 먼저 공격받는 문이기도 하다. 이 글에서는 SSH가 지원하는 인증 방법을 정리하고, 어떤 방법을 쓰고 어떤 방법을 사용하지 말아야 하는지 살펴본다.

SSH 인증 방법 5가지

OpenSSH가 지원하는 사용자 인증 방법은 크게 다섯 가지다.

1. 비밀번호 인증(password)
2. 호스트 기반 인증(host-based)
3. 공개키 인증(public key)
4. 키보드 인터랙티브 인증(keyboard-interactive)
5. 커버로스 인증(GSSAPI, Kerberos)

비밀번호 인증, 공개키 인증, 키보드 인터랙티브 인증은 설정 방법까지 살펴보고, 호스트 기반 인증과 커버로스 인증은 개념만 간단히 소개한다. 이 두 방법의 구체적인 설정은 다음 글에서 다룬다.

 

1. 비밀번호 인증: 절대 사용하지 말 것

가장 익숙하고 설정도 필요 없지만, 가장 위험한 방법이다. 인터넷에 열린 22번 포트는 서버를 만들고 얼마 지나지 않아 전 세계 봇의 스캔 대상이 된다. 비밀번호 인증을 켜 두면 다음 공격에 그대로 노출된다.

• 무차별 대입 공격(brute force attack)
• 유출된 계정 정보를 재사용하는 크리덴셜 스터핑(credential stuffing)
• 흔한 비밀번호 목록을 이용한 사전 공격(dictionary attack)

"비밀번호 쓰고 fail2ban 쓰면 되지 않나요?"라는 반응이 있을 수 있다. fail2ban은 로그인에 반복해서 실패한 IP를 일정 시간 차단해 주는 도구라서 무차별 대입 공격을 늦추는 데는 도움이 된다. 하지만 근본적인 해결책은 아니다. 공격자가 여러 IP로 시도를 분산하면 차단을 피할 수 있고, 유출된 계정 정보를 그대로 넣어 보는 크리덴셜 스터핑은 첫 시도에 성공하면 실패 기록이 남지 않아 막을 수 없다.

fail2ban은 비밀번호 인증의 대안이 아니라, 공개키 인증으로 전환한 뒤 쏟아지는 로그인 시도 로그를 줄여 주는 보조 수단으로 쓰는 것이 맞다.

 

3번의 공개키 인증으로 접속되는 것을 확인한 뒤에 /etc/ssh/sshd_config에서 다음과 같이 끈다.

PasswordAuthentication no

다만 sshd_config만 고쳐서는 설정이 적용되지 않는 경우가 있다. OpenSSH는 같은 옵션이 여러 번 나오면 먼저 읽은 값을 적용하는데, 배포판 기본 설정 파일은 맨 위에서 /etc/ssh/sshd_config.d/ 디렉터리의 파일들을 불러온다. 그래서 이 디렉터리의 파일(예: 50-cloud-init.conf)이 sshd_config의 값을 덮어쓸 수 있다. 실제로 적용된 값은 다음 명령으로 확인해야 한다.

sshd -T | grep -i passwordauthentication

 

2. 호스트 기반 인증(host-based authentication)

사용자 개인이 아니라 접속하는 호스트(컴퓨터) 자체를 신뢰하는 방식이다. 클라이언트 호스트가 자신의 호스트 키(host key)로 서명해서 신원을 증명하면, 서버는 그 호스트와 사용자 이름이 신뢰 목록(/etc/hosts.equiv 등)에 등록되어 있는지 확인한다. 등록되어 있으면 사용자별 인증 없이 로그인을 허용한다. 서버끼리 자동으로 접속해야 하는 내부 클러스터 환경에서 쓰였다.

 

다만 신뢰하는 호스트 한 대가 뚫리면 그 호스트를 통해 다른 서버까지 연쇄적으로 뚫릴 수 있다. 게다가 요즘은 보안의 패러다임이 제로 트러스트(zero trust)로 바뀌면서 잘 쓰이지 않는다. 제로 트러스트는 네트워크 위치나 자산 소유만으로 암묵적인 신뢰를 주지 않고, 접속할 때마다 사용자와 기기를 각각 인증하고 권한을 확인하는 모델이다. 호스트를 통째로 신뢰하고 그 안의 사용자를 개별 인증 없이 통과시키는 호스트 기반 인증은 이 원칙과 맞지 않는다. 일반적인 환경에서는 권장되지 않으며, 구체적인 설정 방법은 다음 글에서 다룬다.

HostbasedAuthentication no

 

3. 공개키 인증: 가장 권장되는 방법

공개키 인증(public key authentication)은 키 쌍을 사용한다.

• 개인키(private key)는 내 PC에만 보관한다.
• 공개키(public key)는 서버의 ~/.ssh/authorized_keys에 등록한다.

접속할 때 클라이언트가 그 세션에만 해당하는 고유 값(세션 식별자)을 포함한 데이터에 개인키로 서명해서 보내면, 서버가 등록된 공개키로 서명을 검증한다. 이 과정에서 개인키 자체는 네트워크로 전송되지 않으므로, 통신이 가로채여도 개인키가 유출되지 않는다.

# 키 생성 (Ed25519 권장)
ssh-keygen -t ed25519 -C "your_email@example.com"

# 서버에 공개키 등록
ssh-copy-id user@서버주소

키를 만들 때 패스프레이즈(passphrase)를 설정해 두면 좋다. 개인키 파일이 유출되더라도 한 번 더 막아 준다. 서버 설정은 다음과 같다.

PubkeyAuthentication yes

 

4. 키보드 인터랙티브 인증: 2단계 인증에 활용하는 방법

키보드 인터랙티브 인증(keyboard-interactive authentication)은 서버가 질문을 보내고 사용자가 답하는 방식이다. 서버가 어떤 질문을 하느냐에 따라 동작이 달라지는데, 보통 PAM(pluggable authentication modules)과 연동된다. 일회용 비밀번호(OTP)나 구글 OTP 같은 2단계 인증을 붙일 때 주로 쓰인다.

 

PAM은 리눅스에서 지원하는 인증 프레임워크로, 필요한 보안 모듈을 플러그인처럼 붙였다 뗄 수 있다. 프로그램마다 인증 기능을 따로 구현하지 않아도 PAM 설정만 바꾸면 OTP 추가, 계정 잠금, 비밀번호 정책 적용 같은 인증 방식을 조정할 수 있다. SSH뿐 아니라 로그인이나 sudo 같은 프로그램도 PAM을 통해 인증하며, 설정 파일은 /etc/pam.d/ 아래에 있다.

 

주의할 점이 하나 있다. PasswordAuthentication no로 꺼도, 키보드 인터랙티브와 PAM이 켜져 있으면 비밀번호를 묻는 프롬프트가 그대로 뜰 수 있다. 결국 비밀번호 인증이 살아 있는 것과 같다. 2단계 인증 용도가 아니라면 함께 꺼 두어야 한다.

KbdInteractiveAuthentication no

(OpenSSH 8.7 미만에서는 ChallengeResponseAuthentication no)

 

2단계 인증을 쓰고 싶다면 공개키와 OTP를 함께 요구하도록 조합할 수 있다.

AuthenticationMethods publickey,keyboard-interactive

이 경우에는 위에서 끈 KbdInteractiveAuthentication을 yes로 두어야 하고, OTP 모듈 설치와 PAM 설정도 따로 필요하다. 배포판에 따라 /etc/pam.d/sshd의 기본 비밀번호 인증 항목을 빼지 않으면 OTP와 함께 비밀번호도 묻는다.

 

5. 커버로스 인증(GSSAPI, Kerberos)

Kerberos는 KDC(key distribution center)라는 신뢰할 수 있는 제3자 서버가 인증을 대신 맡아 주는 방식이다. 사용자가 KDC에서 한 번 인증을 받아 티켓(ticket)을 발급받으면, 이후 각 서버에는 비밀번호를 다시 입력하지 않고 티켓으로 접속할 수 있다. SSH에서는 GSSAPI라는 표준 인터페이스를 통해 연동되며, 여러 서버를 중앙에서 통합 관리하는 기업 환경에서 주로 쓰인다.

KDC 구축이 필요해서 개인 서버에서는 쓸 일이 거의 없다. 구체적인 설정 방법은 다음 글에서 다룬다.

GSSAPIAuthentication no

 

설정을 적용할 때 주의할 점

설정을 바꾼 뒤에는 먼저 문법 오류가 없는지 검사하고 sshd를 재시작한다. 이때 지금 접속 중인 세션은 닫지 말고 그대로 두어야 한다. 새 터미널을 열어 공개키로 접속되는지 확인한 뒤에 기존 세션을 닫아야 한다. 그렇지 않으면 서버에서 스스로 잠겨 버리는 사고가 생길 수 있다.

# 설정 문법 검사
sudo sshd -t

# 재시작 (Debian/Ubuntu는 ssh, RHEL 계열은 sshd)
sudo systemctl restart ssh

 

정리

SSH 인증 방법 5가지를 정리하면 다음과 같다.

• 비밀번호 인증(password)은 무차별 대입 공격과 크리덴셜 스터핑에 노출되므로 사용하지 않는다. fail2ban은 대안이 아니라 보조 수단이다.
• 호스트 기반 인증(host-based)은 신뢰하는 호스트 한 대가 뚫리면 연쇄적으로 뚫릴 수 있고 제로 트러스트 원칙과도 맞지 않아 일반적인 환경에서는 쓰지 않는다.
• 공개키 인증(public key)은 개인키가 네트워크로 전송되지 않아 가장 권장되는 방법이며, 패스프레이즈를 함께 설정하면 좋다.
• 키보드 인터랙티브 인증(keyboard-interactive)은 PAM과 연동해 OTP 같은 2단계 인증을 붙일 때만 쓰고, 그렇지 않으면 꺼 둔다.
• 커버로스 인증(GSSAPI, Kerberos)은 KDC 구축이 필요한 기업 환경용이라 개인 서버에서는 쓰지 않는다.

설정을 바꾼 뒤에는 sshd -T로 실제 적용된 값을 확인하고, 기존 세션을 유지한 채 새 터미널에서 접속을 테스트하자.