서버 공개 전에 SSH부터 점검해야 하는 이유

인터넷에 연결된 Linux 서버는 서비스 포트보다 먼저 SSH 로그인 시도를 받는 경우가 많습니다. 비밀번호를 추측하는 자동화 공격은 특별한 표적이 아니어도 계속 발생하며, 계정 하나가 탈취되면 애플리케이션 설정, 데이터베이스 접속 정보, 배포 키까지 함께 노출될 수 있습니다. SSH 보안은 복잡한 보안 제품을 도입하는 작업이 아니라, 로그인 방법과 접속 가능한 대상을 명확히 제한하는 운영 기본값을 만드는 일입니다.

이 문서는 Ubuntu 계열을 예로 들지만 핵심 원칙은 배포판과 무관합니다. 관리자 계정은 개인별로 분리하고, 공개키 인증을 사용하며, root 직접 로그인과 불필요한 비밀번호 인증을 끕니다. 단, 원격 서버에서 설정을 변경할 때는 현재 접속 세션을 절대 끊지 않은 상태로 새 터미널에서 재접속을 검증해야 합니다. 키 등록 오류나 방화벽 규칙 오류가 있으면 스스로 서버에 접속하지 못할 수 있기 때문입니다.

1. 개인 계정과 공개키 인증 준비

공용 계정 하나를 여러 사람이 사용하면 누가 어떤 작업을 했는지 추적하기 어렵고, 퇴사자나 외부 협력자의 접근을 즉시 회수하기도 어렵습니다. 운영자는 각자 일반 계정을 만들고 필요할 때만 sudo를 사용하도록 구성합니다. 로컬 PC에서 생성한 공개키만 서버의 해당 계정에 등록합니다. 개인 키 파일은 메신저나 저장소에 올리지 않고, 암호문을 설정한 뒤 안전한 기기에 보관해야 합니다.

# 로컬 PC에서 키 생성
ssh-keygen -t ed25519 -a 100 -C "[email protected]"

# 서버에 운영자 계정과 공개키 등록
sudo adduser deploy
sudo usermod -aG sudo deploy
sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo install -m 600 -o deploy -g deploy ~/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys

마지막 명령은 이미 준비된 authorized_keys 파일을 예시로 든 것입니다. 실제로는 ssh-copy-id 또는 안전한 관리 경로를 이용해 공개키 한 줄을 등록할 수 있습니다. 권한이 700, 600보다 느슨하면 SSH가 보안상 키 파일을 무시할 수 있으므로 소유자와 권한을 함께 확인합니다.

2. sshd 설정은 작은 단위로 변경하고 검증하기

설정 파일을 한 번에 크게 고치기보다 /etc/ssh/sshd_config.d/ 아래에 서비스별 정책 파일을 두면 기본 파일과의 충돌을 줄이고 변경 이력을 관리하기 쉽습니다. 아래 예시는 root 로그인과 비밀번호 인증을 막고, 공개키 인증만 허용하는 최소 정책입니다. PermitRootLogin prohibit-password처럼 일부 예외를 남기는 방식보다 운영 원칙을 명확하게 하려면 no를 선택합니다.

sudo tee /etc/ssh/sshd_config.d/90-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
AllowUsers deploy
EOF

sudo sshd -t
sudo systemctl reload ssh

sshd -t는 구문 검증만 수행하므로 reload 전에 반드시 실행합니다. AllowUsers를 사용하면 승인된 계정 외에는 SSH 인증 단계까지 진행할 수 없습니다. 다만 자동 배포 계정이나 긴급 장애 대응 계정을 빼먹으면 접속이 차단되므로 현재 운영 계정 목록을 먼저 정리해야 합니다. 새 터미널에서 ssh deploy@서버주소로 접속 성공을 확인한 뒤에만 기존 세션을 종료합니다.

3. 방화벽은 필요한 포트와 출발지를 함께 정한다

SSH 포트 번호를 바꾸는 것만으로 공격을 막을 수는 없습니다. 스캐너는 열린 포트를 찾기 때문에, 더 중요한 것은 22번 포트를 누가 접근할 수 있는지 제한하는 일입니다. 사무실 고정 IP, VPN 대역, 점프 서버처럼 관리 경로가 정해져 있다면 해당 출발지에만 SSH를 허용합니다. 웹 서버라면 HTTP와 HTTPS만 외부에 열고, 데이터베이스와 Redis 같은 내부 서비스는 공인 인터넷에 노출하지 않습니다.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status numbered

위 IP 주소는 문서용 예시이므로 실제 관리망 주소로 바꿔야 합니다. IP가 자주 바뀌는 환경이면 방화벽을 임의로 넓히기보다 VPN 또는 bastion host를 관리 접점으로 두는 편이 안전합니다. 클라우드 보안 그룹과 서버 내부 방화벽을 함께 쓸 때는 두 정책이 모두 허용해야 접속되므로 변경 순서를 기록해 두는 것이 좋습니다.

4. 로그와 계정 변경을 운영 절차에 넣기

보안 설정은 한 번 적용했다고 끝나지 않습니다. 인증 실패가 급증했는지, 새 공개키가 등록됐는지, sudo 권한이 변경됐는지를 정기적으로 확인해야 합니다. Ubuntu에서는 journalctl로 ssh 서비스 로그를 보거나 auth.log를 확인할 수 있습니다. 반복 실패가 보인다고 바로 특정 IP를 차단하기보다, 실제 사용자의 네트워크 변경 가능성을 확인하고 방화벽·계정 정책·VPN 정책을 함께 판단합니다.

sudo journalctl -u ssh --since "24 hours ago"
sudo grep -E "Failed password|Accepted publickey" /var/log/auth.log | tail -n 100
sudo getent passwd | awk -F: '$3 >= 1000 {print $1, $7}'
sudo find /home -path '*/.ssh/authorized_keys' -type f -ls

월 1회 정도는 접근 권한을 검토해 더 이상 필요 없는 계정과 공개키를 제거하고, 운영 문서에 담당자·접속 경로·긴급 복구 방법을 갱신합니다. 백업 복구용 콘솔이나 클라우드 콘솔 접근 권한도 함께 점검해야 SSH 설정 실수로 인한 장애를 빠르게 복구할 수 있습니다.

배포 전 체크리스트

  • 관리자마다 분리된 일반 계정과 sudo 권한을 사용한다.
  • 공개키 로그인 성공을 새 세션에서 확인한 뒤 비밀번호 인증을 비활성화한다.
  • root 직접 로그인과 사용하지 않는 계정의 SSH 접근을 차단한다.
  • SSH는 신뢰할 수 있는 관리망 또는 VPN에서만 허용한다.
  • 설정 변경 전 sshd -t로 문법을 검사하고, 변경 후 로그와 재접속을 확인한다.
  • 계정·공개키·방화벽 규칙을 정기적으로 검토하고 복구 경로를 유지한다.