SSH 보안은 서버 운영의 첫 번째 방어선이다

인터넷에 연결된 Linux 서버는 짧은 시간 안에 SSH 로그인 시도와 계정 추측 공격을 받는다. 애플리케이션 방화벽이나 웹 서버 설정이 잘되어 있어도 관리용 SSH가 과도하게 열려 있으면 권한 탈취의 출발점이 될 수 있다. 운영 서버의 목표는 “접속을 어렵게 만드는 것”이 아니라, 필요한 관리자는 안전하게 접속하고 불필요한 시도는 인증 단계 이전에 줄이는 것이다.

이 문서는 systemd 기반 Ubuntu 또는 Debian 계열을 예시로 키 기반 인증, 접속 계정 제한, 방화벽, Fail2ban, 점검 순서를 구성한다. 배포판과 운영 정책에 따라 경로와 서비스 이름은 다를 수 있으므로, 현재 접속 세션을 유지한 상태에서 한 단계씩 적용해야 한다.

변경 전에 현재 접속 경로부터 확인한다

원격 서버에서 SSH 설정을 바꾸다가 세션을 끊으면 복구 콘솔이 없는 환경에서는 장애가 될 수 있다. 새 터미널을 하나 더 열어 키 인증으로 로그인되는지 확인하고, 현재 사용 중인 포트와 인증 방식을 기록한다. 설정 파일을 수정하기 전에는 문법 검사와 백업을 수행한다.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.before-hardening
sudo sshd -t
sudo systemctl status ssh
sudo ss -lntp | grep ssh

Ubuntu에서는 서비스 이름이 ssh인 경우가 많고, 일부 배포판에서는 sshd다. 명령 실행 결과로 실제 서비스 이름을 확인한다. 설정 변경 후에는 무조건 기존 세션을 닫기 전에 새 세션으로 재로그인해야 한다.

비밀번호 대신 공개키 인증을 사용한다

공개키 인증은 서버에 공개키만 등록하고 개인키는 관리자 장비에 보관하는 방식이다. 충분한 길이의 키와 개인키 암호를 사용하면 계정 비밀번호 추측 공격의 영향을 크게 줄일 수 있다. 관리자 장비에서 ed25519 키를 만들고 공개키만 서버에 복사한다. 기존 키가 있다면 새 키를 무분별하게 덮어쓰지 않는다.

ssh-keygen -t ed25519 -a 100 -C "admin-key"
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]
ssh -i ~/.ssh/id_ed25519 [email protected]

키 로그인이 검증된 뒤에만 PasswordAuthentication을 no로 바꾼다. 관리자 개인키를 공유 저장소, 메신저, 서버 홈 디렉터리에 복사하는 방식은 피한다. 퇴사자나 협력사 접근이 끝나면 해당 공개키 한 줄만 authorized_keys에서 제거할 수 있도록 개인별 키를 발급하는 것이 좋다.

sshd 설정은 최소 권한 원칙으로 구성한다

root 직접 로그인과 사용하지 않는 인증 방법을 막고, 실제 운영 계정만 허용한다. AllowUsers는 편리하지만 계정을 추가할 때 접속 불가 사고가 생길 수 있으므로 운영 절차에 계정 등록 확인을 포함한다. 포트 변경은 스캔 로그를 줄이는 보조 수단일 뿐 인증과 접근 제어를 대체하지 않는다.

# /etc/ssh/sshd_config.d/99-hardening.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
AllowUsers deploy opsadmin

최근 OpenSSH 설정은 /etc/ssh/sshd_config.d/ 아래의 조각 파일을 읽는 구성이 일반적이다. 배포판의 Include 순서를 확인하고, 같은 항목이 여러 파일에 있으면 최종 적용값을 확인한다. 변경 뒤에는 문법을 검사하고 설정을 다시 읽힌다.

sudo sshd -t && sudo systemctl reload ssh
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|allowusers|maxauthtries'

네트워크에서 관리 접속 범위를 줄인다

SSH 포트는 가능한 한 VPN 대역, 고정 사무실 IP, 운영용 배스천 호스트에서만 허용한다. 모든 인터넷 주소에서 22번 포트를 열어야 하는 사정이 있다면 키 인증과 자동 차단을 함께 적용해야 한다. UFW를 사용하는 서버에서는 규칙 추가 순서와 기존 원격 접속 허용 여부를 반드시 확인한다.

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw deny 22/tcp
sudo ufw status numbered

위 예시의 IP 주소는 문서용 예약 주소다. 실제 운영 환경에서는 관리망의 정확한 CIDR을 사용한다. 클라우드 보안 그룹, 사내 방화벽, 호스트 방화벽이 함께 있을 때는 어느 계층에서 차단되는지 운영 문서에 남겨야 장애 대응이 빨라진다.

반복 로그인 실패는 Fail2ban으로 완화한다

Fail2ban은 인증 로그를 감시해 짧은 시간에 실패를 반복한 주소를 일시 차단한다. 공격자를 완전히 막는 도구는 아니지만, 로그 잡음과 단순 대입 시도를 줄이는 데 유용하다. NAT 환경에서는 여러 사용자가 같은 공인 IP를 공유할 수 있으므로 ban 시간과 실패 횟수를 과도하게 설정하지 않는다.

sudo apt-get update
sudo apt-get install -y fail2ban
sudo tee /etc/fail2ban/jail.d/sshd.local > /dev/null <<'EOF'
[sshd]
enabled = true
maxretry = 4
findtime = 10m
bantime = 1h
EOF
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

운영 중 자신의 IP가 차단된 경우를 대비해 콘솔 접근 수단과 해제 절차를 준비한다. 차단 이벤트는 침해 징후일 수 있으므로 단순히 무시하지 말고, 대상 계정과 원격 주소, 시간대를 로그 수집 시스템에서 함께 확인한다.

운영 체크리스트

  • 개인별 SSH 키 로그인과 새 세션 재로그인을 확인했다.
  • root 직접 로그인과 비밀번호 인증을 비활성화했다.
  • 허용 계정과 관리망 범위를 문서화했다.
  • sshd -t로 문법을 검사한 뒤 reload했다.
  • 방화벽과 클라우드 보안 그룹의 SSH 규칙을 함께 점검했다.
  • 실패 로그인 감시, 키 폐기, 운영자 변경 절차를 정기 점검한다.

SSH 보안은 단일 옵션으로 끝나지 않는다. 인증 방식, 계정 권한, 네트워크 경로, 로그 감시를 함께 관리하고, 변경 후 실제 로그인 테스트까지 완료해야 안정적인 서버 운영 체계가 된다.