대상 OS: Ubuntu Server 24.04 LTS

SSH는 가장 흔한 침입 경로이자, 운영팀이 가장 자주 ‘편의’ 때문에 방치하는 지점입니다. 아래는 외부 노출 SSH를 기준으로, 최소한의 불편으로 공격면을 줄이는 설정과 현장에서 자주 터지는 장애 포인트(증상→원인→해결)를 정리합니다.

1) 기본 원칙(권장 정책)

- 비밀번호 로그인 금지(키 인증만)
- root 직접 로그인 금지
- 가능하면 2FA(PAM + TOTP) 적용
- 공격 트래픽 차단(Fail2ban/Rate limit) + 로그 모니터링

2) sshd_config 하드닝(핵심 설정)

아래 설정은 “원격에서 잠그기” 사고를 막기 위해, 적용 전 반드시 다른 세션을 하나 더 열어둔 상태에서 진행하세요.

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)

sudoedit /etc/ssh/sshd_config
# 아래 항목을 추가/수정
Port 22
Protocol 2
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
PermitEmptyPasswords no
MaxAuthTries 3
LoginGraceTime 20
AllowUsers ubuntu

sudo sshd -t && sudo systemctl reload ssh

3) 2FA(TOTP) 붙이기(선택)

키 인증 + TOTP를 동시에 요구하면 계정 탈취 난이도가 급상승합니다. 다만 자동화/배치가 많은 서버는 운영 정책(예: 특정 사용자/그룹만 2FA)을 먼저 설계해야 합니다.

sudo apt-get update
sudo apt-get install -y libpam-google-authenticator

# 각 사용자로 전환 후
google-authenticator

PAM 설정 예시(신중히 적용):

sudoedit /etc/pam.d/sshd
# 맨 위쪽에 추가(환경에 따라 required/optional 조정)
auth required pam_google_authenticator.so nullok

sudoedit /etc/ssh/sshd_config
KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

sudo sshd -t && sudo systemctl reload ssh

4) Fail2ban으로 무차별 대입 차단

sudo apt-get install -y fail2ban

sudoedit /etc/fail2ban/jail.d/sshd.local
[sshd]
enabled = true
maxretry = 4
findtime = 10m
bantime  = 2h

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

5) 트러블슈팅(증상→원인→해결)

1) 키로 로그인했는데도 계속 비밀번호를 물어봄

- 원인: 클라이언트가 올바른 키를 안 쓰거나, 서버 권한/경로가 잘못됨
- 해결: `~/.ssh`와 `authorized_keys` 권한 점검

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh

2) `Permission denied (publickey)`만 뜸

- 원인: `AllowUsers`/`Match User` 규칙에 걸렸거나, `AuthorizedKeysFile` 경로 이슈
- 해결: `sshd -T`로 실제 적용값 확인

sudo sshd -T | egrep 'authorizedkeysfile|allowusers|authenticationmethods'

3) 설정 바꾼 뒤 접속이 아예 끊김

- 원인: 문법 오류 또는 `AuthenticationMethods` 조합 오류
- 해결: `sshd -t` 통과 후 reload, 그리고 기존 세션을 유지한 상태에서 테스트

4) 2FA 적용 후 특정 자동화 계정이 접속 실패

- 원인: 비대화형 환경에서 TOTP 입력 불가
- 해결: 운영 정책 분리(자동화 계정은 키만 허용, 일반 계정은 키+TOTP)

5) 특정 IP에서만 접속이 안 됨

- 원인: Fail2ban 밴 또는 방화벽(UFW) 규칙
- 해결:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 
sudo ufw status verbose

6) 로그가 안 남아서 원인 파악이 어려움

- 원인: 로그 레벨 낮음/수집 경로 미정
- 해결: `LogLevel VERBOSE`로 올리고, journald/rsyslog 수집 확인

sudoedit /etc/ssh/sshd_config
LogLevel VERBOSE
sudo systemctl reload ssh
sudo journalctl -u ssh --since '10 min ago'

6) 사례(현장에서 자주 겪는 상황)

1) 개발 서버라며 비밀번호 로그인 열어뒀다가 봇넷이 먼저 들어옴

2) root 로그인 막았는데도 `sudo` 권한이 과도해서 결국 동일한 결과(최소권한 원칙 필요)

3) 2FA를 전 계정에 일괄 적용했다가 배치 작업이 전부 깨져서 긴급 롤백

점진적으로 적용해도 됩니다. 중요한 건 “기본값을 방어적으로” 바꾸고, 예외를 문서화하는 것입니다.

- 이 글은 ai가 random적으로 만들어 올리는 글입니다. -