SSH 키 인증으로 다중 서버 관리하기 — 비밀번호 없는 안전한 접속
서버가 2~3대만 넘어가면, 매번 비밀번호를 입력하는 게 번거로워집니다. 더 큰 문제는 보안입니다. 비밀번호 인증은 브루트포스 공격에 취약하고, 복잡한 비밀번호는 기억하기 어렵죠. SSH 키 인증으로 전환하면 보안과 편의성 두 마리 토끼를 잡을 수 있습니다.
Ed25519
권장 키 알고리즘
256bit
키 보안 강도
0회
비밀번호 입력
~/.ssh
키 저장 위치
1왜 키 인증인가
| 항목 | 비밀번호 인증 | 키 인증 |
|---|---|---|
| 브루트포스 공격 | 취약 (조합 시도 가능) | 불가 (키 없이 접속 불가) |
| 편의성 | 매번 입력 필요 | 자동 인증 |
| 자동화 | 스크립트에 비밀번호 하드코딩 위험 | 키 기반 자동화 안전 |
| 다중 서버 | 서버마다 비밀번호 기억 | 하나의 키로 모든 서버 |
| 감사 추적 | 누가 접속했는지 특정 어려움 | 키별로 접속자 구분 가능 |
핵심: 비밀번호를 네트워크로 보내지 않음
키 인증은 개인키 자체를 서버에 전송하지 않습니다. 서버가 보낸 챌린지를 개인키로 서명해서 돌려보내는 방식이라, 네트워크를 도청당해도 키를 탈취할 수 없습니다.
2SSH 키 생성과 배포
키 생성
# Ed25519 키 생성 (권장) ssh-keygen -t ed25519 -C "user@workstation" # 출력: # Generating public/private ed25519 key pair. # Enter file in which to save the key (~/.ssh/id_ed25519): [Enter] # Enter passphrase: [선택사항, 추가 보안 레이어] # 생성 확인 ls -la ~/.ssh/ # id_ed25519 ← 개인키 (절대 공유 금지) # id_ed25519.pub ← 공개키 (서버에 등록)
왜 Ed25519인가?
RSA보다 키 길이가 짧으면서(256bit) 보안 강도는 RSA 3072bit과 동등합니다. 서명/검증 속도도 빠릅니다. 2026년 기준으로 신규 키 생성 시 Ed25519가 표준입니다.
키 배포
# 방법 1: ssh-copy-id (가장 간편) ssh-copy-id -i ~/.ssh/id_ed25519.pub user@10.x.x.x # 방법 2: 수동 복사 cat ~/.ssh/id_ed25519.pub | ssh user@10.x.x.x "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys" # 방법 3: 여러 서버에 한 번에 배포 for server in server-a server-b server-c; do ssh-copy-id -i ~/.ssh/id_ed25519.pub user@$server done # 배포 확인 (비밀번호 없이 접속되면 성공) ssh user@10.x.x.x
권한 설정 주의
SSH는 파일 권한이 느슨하면 키를 무시합니다. 반드시 다음 권한을 확인하세요:~/.ssh (700),authorized_keys (600),id_ed25519 (600).
3비밀번호 인증 비활성화
키 인증이 정상 동작하는 것을 확인한 후, 비밀번호 인증을 끕니다. 반드시 키로 접속이 되는 것을 먼저 확인한 뒤에 진행하세요. 순서를 바꾸면 서버에 접속할 수 없게 됩니다.
# /etc/ssh/sshd_config 수정 sudo nano /etc/ssh/sshd_config # 다음 항목 변경 PasswordAuthentication no ChallengeResponseAuthentication no UsePAM yes # Ubuntu/Debian에서는 UsePAM yes를 유지하는 것이 안전합니다 PubkeyAuthentication yes # SSH 서비스 재시작 sudo systemctl restart sshd # 주의: 현재 세션을 유지한 채로 새 터미널에서 접속 테스트 # 문제가 있으면 현재 세션에서 롤백 가능
잠금 방지 체크리스트
- 1. 키 인증으로 접속 성공 확인 (새 터미널에서)
- 2. 현재 SSH 세션은 절대 닫지 말 것
- 3. sshd_config 수정 후 새 세션으로 접속 테스트
- 4. 문제 발생 시 기존 세션에서 설정 복구
- 5. 콘솔 접근 수단(IPMI, 물리 모니터) 확보 권장
4SSH config로 별칭 관리
서버가 여러 대이면 IP 주소, 포트, 사용자명을 매번 입력하기 번거롭습니다.~/.ssh/config 파일에 별칭을 등록하면ssh ai-server처럼 한 단어로 접속할 수 있습니다.
# ~/.ssh/config
# AI 서버
Host ai-server
HostName 10.x.10.11
User admin
Port 22
IdentityFile ~/.ssh/id_ed25519
# 백업 서버
Host backup
HostName 10.x.10.20
User root
Port 2222
IdentityFile ~/.ssh/id_ed25519
# 리버스 프록시
Host proxy
HostName 10.x.10.5
User admin
Port 22
IdentityFile ~/.ssh/id_ed25519
# VPN 통해서만 접속 가능한 서버 (점프 호스트 경유)
Host internal-db
HostName 10.x.10.50
User dbadmin
ProxyJump proxy
# 공통 설정 (모든 호스트에 적용)
Host *
ServerAliveInterval 60
ServerAliveCountMax 3
AddKeysToAgent yes# 사용 예시 ssh ai-server # 10.x.10.11에 admin으로 접속 ssh backup # 10.x.10.20에 root로 포트 2222 접속 ssh internal-db # proxy를 경유하여 내부 DB 서버 접속 # SCP, rsync에도 동일하게 적용 scp file.txt ai-server:/home/admin/ rsync -avz ./data/ backup:/backup/data/
ProxyJump 활용
외부에서 직접 접근할 수 없는 내부 서버에는 ProxyJump로 점프 호스트를 경유할 수 있습니다. VPN 접속 + ProxyJump를 조합하면, 복잡한 네트워크 구성에서도 한 번의 ssh 명령으로 접속 가능합니다.
5중앙 관리 패턴
팀원이 여러 명이고 서버도 여러 대인 경우, 키를 체계적으로 관리할 필요가 있습니다.
1인 1키 원칙
각 팀원이 자신의 키 페어를 생성합니다. 공개키만 수집하여 서버에 등록합니다. 퇴사 시 해당 공개키만 삭제하면 접근이 즉시 차단됩니다.
authorized_keys 중앙 관리
각 서버의 authorized_keys 파일을 Git으로 관리하거나, Ansible 등 자동화 도구로 배포합니다. 누가 어떤 서버에 접근할 수 있는지 한눈에 파악 가능합니다.
일괄 명령 실행
SSH config와 키 인증이 갖춰지면, for 루프나 parallel-ssh로 여러 서버에 동시에 명령을 실행할 수 있습니다.
# 여러 서버에 동시 명령 실행 for host in ai-server backup proxy; do echo "=== $host ===" ssh $host "uptime && df -h / && free -h" echo "" done # parallel-ssh로 병렬 실행 (더 빠름) # sudo apt install pssh parallel-ssh -H "ai-server backup proxy" -i "uptime" # 전체 서버 패키지 업데이트 for host in ai-server backup proxy; do ssh $host "sudo apt update && sudo apt upgrade -y" & done wait
6보안 체크리스트
| 항목 | 설정 | 효과 |
|---|---|---|
| root 직접 로그인 차단 | PermitRootLogin no | root 계정 직접 접속 차단, sudo 사용 강제 |
| 포트 변경 | Port 2222 (예시) | 기본 포트 스캐닝 회피 |
| 접속 IP 제한 | AllowUsers admin@10.x.* | 특정 IP 대역에서만 접속 허용 |
| fail2ban 설치 | 5회 실패 시 10분 차단 | 브루트포스 공격 방어 |
| 빈 비밀번호 차단 | PermitEmptyPasswords no | 비밀번호 없는 계정 접속 차단 |
fail2ban 설정
# 설치 sudo apt install fail2ban # SSH 전용 설정 sudo nano /etc/fail2ban/jail.local [sshd] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 5 bantime = 600 findtime = 600 # 서비스 시작 sudo systemctl enable fail2ban sudo systemctl start fail2ban # 차단 현황 확인 sudo fail2ban-client status sshd
키 인증 + fail2ban 조합이 최선
비밀번호 인증을 꺼도, SSH 포트가 열려 있으면 접속 시도 자체는 들어옵니다. fail2ban은 반복 접속 시도를 자동으로 차단하여 로그 노이즈를 줄이고 서버 부하를 낮춥니다. 여러 서버를 한 화면에서 모니터링하려면 Grafana 통합 모니터링을 참고하세요.
정리
SSH 키 인증 관리 체크리스트
- Ed25519 키 생성 — RSA보다 짧고 강력한 보안
- ssh-copy-id로 공개키를 각 서버에 배포
- 키 접속 확인 후 비밀번호 인증 비활성화 (순서 중요!)
- ~/.ssh/config로 서버 별칭, 포트, 사용자 관리
- ProxyJump로 점프 호스트 경유 접속 설정
- root 직접 로그인 차단, SSH 포트 변경
- fail2ban으로 반복 접속 시도 자동 차단
- 퇴사자 공개키 삭제로 즉시 접근 차단
SSH 키 인증은 서버 관리의 가장 기본적인 보안 조치이면서, 동시에 편의성을 크게 높여줍니다. 서버가 2대만 되어도 설정할 가치가 있고, 5대 이상이면 반드시 필요합니다. 키 생성부터 배포, 비밀번호 차단, config 설정까지 한 번에 끝내세요.
본 글의 IP 주소, 사용자명, 호스트명은 모두 예시입니다. 실제 환경에 맞게 변경하여 적용하세요. SSH 설정 변경 시 기존 세션을 유지한 상태에서 테스트하는 것을 강력히 권장합니다. 본 콘텐츠의 비상업적 공유는 자유이나, 상업적 이용 시 문의 페이지를 통해 연락 바랍니다.
서버 보안 점검이 필요하신가요?
Treeru는 SSH 보안 설정, 방화벽 구성, 서버 인프라 점검 서비스를 제공합니다. 키 인증 전환부터 보안 강화까지 한 번에 처리해 드립니다.
서버 보안 상담댓글
(4개)로그인하면 댓글을 작성할 수 있습니다.
서버 5대 관리하면서 전부 비밀번호로 접속하고 있었는데, 이 글 보고 키 인증으로 전환했습니다. 보안도 보안이지만 편의성이 훨씬 좋아졌어요.
ed25519 키를 쓰는 이유가 잘 설명되어 있네요. 보안도 강하고 키 길이도 짧아서 관리하기 편합니다. ProxyJump 설정도 유용하게 쓰고 있습니다.
fail2ban 설정까지 다뤄줘서 좋습니다. 비밀번호 인증 끄기 전에 키가 제대로 등록되었는지 확인하라는 주의사항이 정말 중요하더라고요. 안 그러면 접속 불가...
관련 글
© 2026 TreeRU. All rights reserved.
본 콘텐츠의 저작권은 TreeRU에 있으며, 출처를 밝히지 않은 무단 전재 및 재배포를 금합니다. 인용 시 출처(treeru.com)를 반드시 명시해 주세요.