리눅스 서버를 운영하다 보면 SSH를 이용해 원격으로 서버에 접속하는 일이 많습니다. SSH는 인터넷을 통해 서버에 안전하게 접속할 수 있도록 해주는 대표적인 원격 접속 방식입니다.
처음 서버를 만들었을 때는 일반적으로 아이디와 비밀번호를 이용해 접속하는 경우가 많습니다. 하지만 서버가 인터넷에 공개되어 있다면 비밀번호를 반복해서 추측하는 공격에 노출될 수 있기 때문에 보다 안전한 로그인 방법을 고려하는 것이 좋습니다.
그중 대표적인 방법이 SSH 공개키 인증입니다.
SSH 키 인증은 비밀번호 대신 암호학적으로 생성된 한 쌍의 키를 이용해 사용자를 확인하는 방식입니다. 개인키는 접속하는 컴퓨터에 보관하고 공개키는 서버에 등록합니다. Ubuntu 공식 문서에서도 Ed25519 방식의 SSH 키 생성을 권장하고 있습니다.
이번 글에서는 Ubuntu 리눅스 서버를 기준으로 SSH 키를 이용한 원격 접속을 설정하고, 정상적으로 키 로그인이 확인된 후 비밀번호 로그인을 차단하는 과정을 알아보겠습니다.
1. SSH 키 인증이란?
SSH 키 인증을 이해하려면 먼저 두 개의 키가 있다는 것을 알아야 합니다.
하나는 개인키(Private Key)이고 다른 하나는 공개키(Public Key)입니다.
개인키는 사용자의 컴퓨터에 보관하며 다른 사람에게 절대로 전달해서는 안 됩니다.
공개키는 접속하려는 리눅스 서버에 등록합니다.
쉽게 설명하면 개인키가 열쇠이고 공개키가 서버에 설치된 잠금장치라고 생각하면 됩니다.
서버는 접속 요청을 받은 뒤 등록된 공개키와 사용자가 가진 개인키가 서로 맞는지 확인합니다.
이 방식의 장점은 서버에 비밀번호를 직접 입력하지 않고도 안전하게 인증할 수 있다는 것입니다.
2. 리눅스 서버에 OpenSSH 설치하기
먼저 서버에 SSH 서버 프로그램이 설치되어 있는지 확인합니다.
Ubuntu에서는 다음 명령으로 OpenSSH 서버를 설치할 수 있습니다.
sudo apt update
sudo apt install openssh-server
설치가 끝났다면 SSH 서비스가 정상적으로 실행되고 있는지 확인합니다.
sudo systemctl status ssh
정상적으로 실행되고 있다면 active (running)과 같은 상태가 표시됩니다.
Ubuntu 공식 문서에서도 openssh-server 패키지를 설치한 뒤 SSH 서비스를 설정하는 방법을 안내하고 있습니다.
3. 접속할 컴퓨터에서 SSH 키 생성하기
이제 서버에 접속할 컴퓨터에서 SSH 키를 생성합니다.
Linux나 macOS에서는 터미널을 열고 다음 명령을 입력할 수 있습니다.
ssh-keygen -t ed25519
명령을 실행하면 키 파일을 저장할 위치와 패스프레이즈를 입력하라는 메시지가 나타납니다.
특별한 이유가 없다면 기본 저장 경로를 사용해도 됩니다.
일반적으로 다음과 같은 두 파일이 생성됩니다.
~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub
여기서 id_ed25519가 개인키이고 id_ed25519.pub가 공개키입니다.
개인키는 절대로 다른 사람에게 전달하거나 공개해서는 안 됩니다.
가능하다면 개인키 자체에도 패스프레이즈를 설정하는 것이 좋습니다.
4. 공개키를 서버에 등록하기
키를 생성했다면 공개키를 서버에 등록해야 합니다.
Linux나 macOS에서는 ssh-copy-id를 이용할 수 있습니다.
ssh-copy-id 사용자이름@서버IP
예를 들어 서버 사용자가 ubuntu이고 서버 IP가 203.0.113.20이라면 다음과 같은 형태입니다.
ssh-copy-id ubuntu@203.0.113.20
처음에는 기존 비밀번호를 입력해야 할 수 있습니다.
명령이 정상적으로 완료되면 서버의 해당 사용자 계정에 공개키가 등록됩니다.
Ubuntu 공식 문서에서도 ssh-copy-id를 사용해 공개키를 서버의 authorized_keys에 추가하는 방법을 안내하고 있습니다.
5. SSH 키로 로그인 테스트하기
이제 가장 중요한 테스트를 진행합니다.
현재 SSH 연결을 바로 종료하지 말고, 새로운 터미널 창을 하나 더 열어서 키 기반 접속을 테스트하는 것이 안전합니다.
다음과 같이 접속합니다.
ssh 사용자이름@서버IP
예를 들어 다음과 같습니다.
ssh ubuntu@203.0.113.20
정상적으로 접속된다면 SSH 키 인증이 제대로 설정된 것입니다.
개인키에 패스프레이즈를 설정했다면 서버 계정의 비밀번호 대신 개인키의 패스프레이즈를 입력하게 될 수 있습니다.
이 단계가 매우 중요합니다.
키 로그인이 정상적으로 확인되기 전에 비밀번호 로그인을 차단하면 서버에 접속하지 못할 수 있습니다.
6. SSH 설정 파일 백업하기
키 로그인이 확인됐다면 이제 SSH 설정을 변경할 차례입니다.
SSH 서버의 주요 설정 파일은 다음 위치에 있습니다.
/etc/ssh/sshd_config
Ubuntu의 최신 설정 구조에서는 /etc/ssh/sshd_config.d/ 아래에 별도의 설정 파일을 추가하는 방식도 사용할 수 있습니다. Ubuntu 공식 문서에서는 기본 설정 파일과 함께 이 디렉터리의 설정 파일을 사용할 수 있다고 설명합니다.
설정을 변경하기 전에 백업을 만들어두는 것이 좋습니다.
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup
서버가 SSH로만 관리되는 환경이라면 설정을 잘못 변경했을 때 원격 접속 자체가 끊길 수 있으므로 특히 주의해야 합니다. Ubuntu 공식 문서 역시 SSH 설정을 변경한 뒤 재시작하기 전에 문법 검사를 하도록 안내합니다.
7. 비밀번호 로그인 차단하기
이제 SSH 서버에서 비밀번호 인증을 차단합니다.
설정 파일을 엽니다.
sudo nano /etc/ssh/sshd_config
다음 설정을 찾습니다.
PasswordAuthentication yes
또는 주석 처리된 설정이 있다면 다음과 같이 변경하거나 적절한 설정 파일에 추가합니다.
PasswordAuthentication no
이 설정은 SSH를 통한 비밀번호 인증을 허용하지 않도록 하는 역할을 합니다.
OpenSSH의 PasswordAuthentication 설정은 비밀번호 인증 허용 여부를 결정합니다.
다만 SSH에는 비밀번호 인증과 별개로 키보드 인터랙티브 인증 등 다른 인증 방식이 존재할 수 있으므로, 실제 운영 환경에서는 자신이 사용하는 인증 방식을 확인한 뒤 설정하는 것이 좋습니다.
8. 공개키 인증은 활성화하기
SSH 키를 사용하려면 공개키 인증이 허용되어 있어야 합니다.
설정에서 다음 항목을 확인합니다.
PubkeyAuthentication yes
PubkeyAuthentication은 공개키 인증을 허용하는 설정입니다. OpenSSH 설정 문서에서도 이 옵션을 통해 공개키 인증 사용 여부를 지정할 수 있다고 설명합니다.
따라서 일반적인 키 기반 로그인 환경에서는 다음과 같은 구성을 사용할 수 있습니다.
PubkeyAuthentication yes
PasswordAuthentication no
이렇게 하면 SSH 로그인에서 공개키 인증을 사용하고 일반적인 비밀번호 인증은 차단하는 방향으로 설정할 수 있습니다.
9. root 계정의 직접 로그인도 확인하기
SSH 보안을 강화할 때 root 계정의 직접 로그인도 함께 검토하는 것이 좋습니다.
다음 설정을 사용할 수 있습니다.
PermitRootLogin no
이 설정은 SSH를 통한 root 직접 로그인을 차단하는 역할을 합니다.
다만 현재 서버에 어떤 관리자 계정이 존재하는지, 해당 계정에 sudo 권한이 있는지 먼저 확인해야 합니다.
관리자 권한을 가진 별도의 사용자 계정으로 정상적으로 로그인할 수 있는지 확인한 후 root SSH 로그인을 제한하는 것이 안전합니다.
10. 설정 변경 후 반드시 문법 검사하기
SSH 설정을 변경했다면 바로 서비스를 재시작하지 않는 것이 좋습니다.
먼저 설정 파일에 오류가 없는지 확인합니다.
sudo sshd -t
아무런 오류 메시지가 나오지 않는다면 설정 문법이 정상적으로 인식된 것입니다.
Ubuntu 공식 문서에서도 SSH 설정을 변경한 뒤 sudo sshd -t를 이용해 설정을 검사한 다음 SSH 서비스를 재시작하도록 안내합니다.
이 과정은 매우 중요합니다.
설정 파일에 오타가 있거나 잘못된 옵션을 입력한 상태에서 SSH 서비스를 재시작하면 원격 서버에 접속하지 못하는 문제가 발생할 수 있습니다.
11. SSH 서비스 재시작하기
문법 검사가 정상적으로 끝났다면 SSH 서비스를 다시 시작합니다.
sudo systemctl restart ssh
그리고 새로운 터미널 창에서 다시 SSH 접속을 테스트합니다.
ssh 사용자이름@서버IP
이번에는 공개키 인증을 통해 정상적으로 로그인되는지 확인합니다.
기존 SSH 연결을 바로 끊지 않고 새로운 연결에서 테스트하는 것이 안전합니다.
12. 비밀번호 로그인이 차단되었는지 확인하기
키 로그인이 정상적으로 되는 것을 확인했다면 비밀번호 로그인 차단 상태를 점검할 수 있습니다.
다른 인증 수단을 사용하지 않는 테스트 환경에서 비밀번호로 접속을 시도했을 때 인증이 거부된다면 설정이 의도대로 적용된 것입니다.
또한 SSH 서버의 실제 적용 설정을 확인하는 방법도 있습니다.
환경에 따라 다음 명령으로 확인할 수 있습니다.
sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'
예를 들어 다음과 비슷한 결과가 나타날 수 있습니다.
passwordauthentication no
pubkeyauthentication yes
permitrootlogin no
다만 배포판의 설정 파일 구조나 추가 설정에 따라 결과가 달라질 수 있으므로 실제 출력 내용을 기준으로 판단해야 합니다.
13. SSH 접속이 갑자기 안 된다면?
SSH 키 설정 후 접속이 되지 않는다면 당황하지 말고 하나씩 확인해야 합니다.
먼저 서버에서 SSH 서비스 상태를 확인합니다.
sudo systemctl status ssh
로그를 확인하는 것도 도움이 됩니다.
sudo journalctl -u ssh.service
Ubuntu 공식 문서에서는 SSH 키 인증 문제를 확인할 때 SSH 서비스의 로그를 살펴보는 방법을 안내하고 있습니다.
또한 다음 항목을 확인해야 합니다.
- 개인키가 올바른 위치에 있는지
- 공개키가 서버의 authorized_keys에 등록됐는지
- 사용자 이름이 정확한지
- SSH 포트가 올바른지
- 서버 방화벽에서 SSH 접속이 허용되어 있는지
- .ssh와 authorized_keys의 권한이 적절한지
- SSH 설정 파일에 오타가 없는지
특히 authorized_keys의 권한이 지나치게 개방되어 있으면 SSH가 키를 거부할 수 있으므로 파일 권한도 확인하는 것이 좋습니다. Ubuntu 공식 문서에서도 authorized_keys의 권한을 점검하도록 안내하고 있습니다.
14. SSH 키 관리에서 주의할 점
SSH 키 인증은 비밀번호 인증보다 편리하고 강력한 방법이지만 개인키를 안전하게 관리하는 것이 중요합니다.
가장 중요한 원칙은 개인키를 다른 사람에게 전달하지 않는 것입니다.
개인키 파일을 이메일이나 메신저로 보내거나 공개 저장소에 올리는 것도 피해야 합니다.
또한 개인키에 패스프레이즈를 설정하면 개인키 파일이 노출되었을 때 추가적인 보호막이 될 수 있습니다.
서버를 여러 대 운영한다면 각 서버와 용도에 맞게 키를 구분해 관리하는 것도 좋은 방법입니다.
마무리
SSH 서버의 보안을 강화하는 가장 기본적인 방법 중 하나가 공개키 기반 인증을 설정하고 비밀번호 로그인을 제한하는 것입니다.
전체적인 과정은 다음과 같이 정리할 수 있습니다.
OpenSSH 설치 → SSH 키 생성 → 공개키 서버 등록 → 키 로그인 테스트 → SSH 설정 백업 → 공개키 인증 확인 → 비밀번호 인증 차단 → 설정 문법 검사 → SSH 서비스 재시작 → 새로운 연결에서 최종 테스트
특히 중요한 것은 순서입니다.
처음부터 비밀번호 로그인을 차단하는 것이 아니라 SSH 키 로그인이 정상적으로 작동하는 것을 먼저 확인한 뒤 비밀번호 인증을 차단해야 합니다.
그리고 SSH 설정을 변경한 후에는 반드시 sshd -t로 문법을 검사하는 습관을 들이는 것이 좋습니다.
리눅스 서버를 인터넷에 공개해서 운영한다면 SSH 보안은 한 번 설정하고 끝나는 작업이 아닙니다. 사용하지 않는 계정을 정리하고, 접근 가능한 사용자를 제한하며, 로그를 주기적으로 확인하는 등 지속적으로 관리하는 것이 중요합니다.
결국 안전한 서버 운영의 핵심은 복잡한 설정을 많이 추가하는 것이 아니라 필요한 사용자만, 필요한 방식으로, 필요한 서버에 접근하도록 제한하는 것입니다.