SSH 서버 설정 강화 방법
마지막 업데이트:
sshd_config 파일은 SSH 서버의 보안 태세 전체를 담은 단 하나의 텍스트 파일입니다. 그런데 대부분의 시스템에서는 보안이 아니라 호환성에 최적화된 상태로 출하됩니다. 비밀번호 로그인이 기본으로 켜져 있고, root는 키만 사용하면 로그인할 수 있으며, 유휴 세션은 절대 종료되지 않고, 서버가 제공하는 알고리즘은 수년 전에 설치된 OpenSSH 버전이 정한 것입니다. 강화란 2021년 체크리스트를 복사하는 일이 아닙니다. 알고리즘은 폐지되고, 기본값은 바뀌며, 5년 전에 모범적이던 설정이 오늘은 취약할 수 있습니다. 이 글에서는 각 변경이 실제로 무엇을 하는지, 결정 순서가 왜 중요한지, 그리고 스스로를 잠그지 않고 새 설정을 테스트하는 방법을 설명합니다. 자신의 파일은 SSH 서버 설정 감사 도구에서 한 줄씩 감사할 수 있습니다. 2026-11-13 기준 베이스라인과 대조하며, 모든 과정이 브라우저 안에서 이루어집니다.
기본값은 출발점이지 강화 태세가 아니다
OpenSSH는 새로 설치했을 때 가능한 한 많은 사람에게 동작하도록 선택된 기본값과 함께 출하됩니다. 그것이 바로 기본값이 보안 태세가 아닌 이유입니다. sshd_config 매뉴얼 페이지에 기록된 현재 기본값에는 PasswordAuthentication yes, PermitRootLogin prohibit-password, MaxAuthTries 6, LoginGraceTime 120초, ClientAliveInterval 0이 포함됩니다. 마지막 0은 유휴 세션이 절대 종료되지 않는다는 뜻입니다. 어느 것도 버그가 아닙니다. 모두 의도적인 호환성 선택이며, 강화 감사에서는 모두 지적 사항이 됩니다.
실질적인 결과는 이렇습니다. 한 번도 강화한 적 없는 서버는 지금도 비밀번호 추측으로 도달할 수 있고, 도난당한 키로 root 로그인을 지금도 받아들이며, 버려진 세션을 무기한 열어 둡니다. 기본값은 시간과 함께 바뀝니다. OpenSSH 10.6이 가져오는 것은 OpenSSH 7이 가져오던 것과 다릅니다. 따라서 "나는 아무것도 바꾼 적이 없다"는 중립적인 진술이 아닙니다. 보안 태세가 우연히 설치된 버전이 정한 그대로라는 뜻이며, 이를 아는 유일한 방법은 파일을 읽는 것입니다. 이것이 감사의 첫 번째 일입니다. 보이지 않는 기본값을 보이게 만드는 것. 파일에 나타나지 않은 지시어도 여전히 유효하기 때문입니다.
비밀번호를 끄는 것이 포트 변경보다 항상 낫다
sshd_config에서 가장 효과적인 단일 변경은 PasswordAuthentication no와 PubkeyAuthentication yes의 조합입니다. 이 순간부터 추측했든, 유출됐든, 피싱으로 빼앗겼든, 어떤 비밀번호도 세션을 열 수 없습니다. 데몬이 그 종류의 증명을 더 이상 받아들이지 않기 때문입니다. 키 인증은 공격을 "인간이 고른 비밀을 추측하는 것"에서 "네트워크를 절대 거치지 않는 개인 키 파일을 훔치는 것"으로 바꿉니다. 그래서 Mozilla를 포함한 모든 강화 베이스라인이 여기서 시작합니다. 이 글에서 단 하나만 가져가신다면 바로 이것입니다. 키 쌍을 생성하고(SSH 키 스위트와 관련 글 SSH 키 해설 참조), 공개 키를 설치하고, 그 키로 로그인할 수 있는지 확인한 뒤에야 비밀번호를 끄십시오.
반면 포트를 22에서 잘 알려지지 않은 포트로 바꾸는 것은 강화가 아니라 은폐입니다. 로그의 잡음은 줄어듭니다. 인터넷 전체를 스캔하는 스캐너 대부분은 22번 포트만 두드리기 때문입니다. 그러나 스캔할 수고를 들이는 공격자는 막지 못합니다. 포트 스캔은 수 초 만에 데몬을 찾아내고, 그 뒤의 데몬은 설정만큼만 강합니다. 따라서 감사 도구는 22가 아닌 포트를 정보로만 취급하고, 점수가 매겨지는 개선으로는 절대 보지 않습니다. 스위치를 뒤집기 전에 알아둘 함정이 하나 있습니다. PAM을 사용하는 시스템에서는 PasswordAuthentication no만으로는 충분하지 않습니다. 키보드 대화형 인증이 PAM이 비밀번호를 받아들이도록 할 수 있기 때문에, /etc/pam.d/sshd의 PAM 스택도 비밀번호를 거부해야 합니다. Mozilla 가이드라인은 이를 명시하고 있으며, 가장 자주 빠뜨리는 변경의 나머지 절반입니다.
root 로그인: prohibit-password가 실제로 허용하는 것
PermitRootLogin에는 네 가지 값이 있으며, 그 차이는 감사 추적이 있느냐 없느냐의 차이입니다. 기본값인 prohibit-password는 root 로그인을 허용합니다. 단, 비밀번호로는 안 됩니다. 도난당한 root 키는 그래도 그대로 들어오고, 세션이 root가 된 뒤에는 로그에 어떤 관리자인지를 구분할 단서가 남지 않습니다. Mozilla의 Modern 프로파일은 이를 No로 설정합니다. 이것이 강화된 답입니다. root는 결코 로그인 계정이 되어서는 안 됩니다. 이름이 있는 사용자로 로그인하고 sudo를 사용하십시오. 그러면 모든 특권 작업이 특정인에게 귀속됩니다.
중간 값들이 존재하는 데는 이유가 있으며, 두려워하기보다 아는 것이 좋습니다. forced-commands-only는 제시된 키가 authorized_keys에서 단일 명령으로 제한된 경우에만 root 로그인을 허용합니다. 백업 및 모니터링 스크립트가 사용하는 패턴이며, 자동화를 위한 정당하고 의도적인 선택입니다. 정당하지 않은 것은 yes입니다. root의 비밀번호 로그인을 허용하며, 모든 감사에서 오류가 됩니다. 실용적인 규칙은 이렇습니다. 사람이 root로 로그인한다면 설정이 잘못된 것입니다. 스크립트라면 키를 하나의 명령으로 제한하고 주석에 그렇게 적어 두십시오. 그렇지 않으면 다음에 파일을 읽는 사람이 이를 "고치려" 할 것입니다.
알고리즘 폐지는 움직이는 표적이다
설정에 있는 알고리즘에는 유효 기한이 있으며, 생각보다 짧습니다. OpenSSH 10.0(2025-04-09 릴리스)은 DSA(ssh-dss) 지원을 완전히 제거하고, 유한체 Diffie-Hellman을 서버 기본 키 교환에서 빼고, 포스트 양자 하이브리드인 mlkem768x25519-sha256을 기본 키 합의로 만들었습니다. 2021년 블로그 글에서 복사한 설정에는 diffie-hellman-group1-sha1, 3des-cbc, arcfour, hmac-md5가 여전히 나열되어 있을 수 있습니다. 현대 감사에서는 모두 오류이며, 그중 일부는 설치된 데몬이 더 이상 지원조차 하지 않습니다. 설정은 변하지 않았습니다. 세상이 변했습니다.
그래서 강화 베이스라인에는 날짜가 필요하고, 재확인은 사후 생각이 아니라 작업의 일부입니다. Mozilla의 Modern 프로파일(curve25519 키 교환, chacha20-poly1305 및 AES-GCM 암호, SHA-2 암호화 후 인증(EtM) MAC)은 참조 표준이지만, OpenSSH 10.0이 기본으로 만든 포스트 양자 키 교환보다 먼저 작성되었습니다. 그래서 2026년 감사에서는 그에 더해 mlkem768x25519-sha256과 sntrup761x25519-sha512도 받아들입니다. 최신 상태를 유지하는 습관은 비용이 적게 듭니다. 1년에 한두 번 서버에서 ssh -Q kex, ssh -Q cipher, ssh -Q mac을 실행해 설치된 버전이 실제로 무엇을 제공하는지 확인하고, 최신 Mozilla 가이드라인과 대조한 뒤, 같은 파일에 대해 감사 도구를 다시 실행하십시오. 2021년의 깨끗한 점수는 역사 문서이지 현재 문서가 아닙니다.
Match 블록과 Include: 깨끗한 감사가 거짓말하는 두 가지 방법
설정 파일은 설정의 평평한 목록이 아닙니다. 조건 분기가 있는 프로그램이며, 두 가지 기능 때문에 강화된 것처럼 읽히는 파일이 그렇지 않은 것처럼 동작할 수 있습니다. 첫 번째는 Match 블록입니다. Match User, Match Group, Match Address 블록 안의 지시어는 기준이 충족될 때만 적용되며, 매뉴얼 페이지는 명시합니다. 키워드가 충족된 여러 Match 블록에 나타나면 첫 번째 인스턴스만 적용된다고 말입니다. 전역 PasswordAuthentication no 뒤에 특정 그룹에 대해 조용히 비밀번호를 다시 활성화하는 Match 블록이 이어지는 것은 실제 설정이며, 한 줄씩 읽는 방식이 정확히 놓치는 종류의 것입니다. Match 블록 안의 지적은 조건부이지, 결코 전역이 아니며, 정직한 감사는 그렇게 범위를 정합니다.
두 번째는 Include입니다. 최신 배포판은 sshd_config를 여러 파일로 나눕니다. 보통 /etc/ssh/sshd_config.d/*.conf이며, Include 지시어는 그 위치에서 사전 순으로 해당 파일들을 가져옵니다. 먼저 얻은 값이 승리하므로, 포함된 파일에 설정된 지시어는 주 파일 뒤쪽의 같은 지시어를 가립니다. 읽고 있는 줄이 실제로 적용되는 줄이 아닌 것입니다. 브라우저에서 실행되는 감사 도구는 Include를 따라갈 수 없습니다. 파일이 사용자의 기기에 없기 때문입니다. 그래서 "따라가지 않음"으로 표시하고 경로를 나열합니다. 감사할 때는 하나의 파일이 아니라 디렉터리 전체를 감사하고, 중복된 지시어는 무시할 수 있는 오타가 아니라는 점을 기억하십시오. 첫 번째가 승리하고, 두 번째는 다음에 파일을 편집할 사람을 혼란스럽게 할 뿐인 죽은 텍스트입니다.
안전한 적용: 문을 닫기 전에 테스트하라
sshd_config 변경에는 모두 같은 위험이 따릅니다. 오타 하나가 데몬 재시작을 거부하게 할 수 있고, 문법은 맞지만 잘못된 설정이 여러분 자신을 거부할 수 있습니다. 둘 다 피하는 적용 절차는 짧고 협상할 여지가 없습니다. 먼저 실행 중인 서비스에 손대기 전에 sshd -t로 문법을 검사하십시오. 파일을 파싱하고 아무것도 시작하지 않고 오류를 보고합니다. 그런 다음 데몬을 재시작하거나 다시 로드하고, 그 뒤에야 테스트하십시오. 설정을 편집하면서 유일한 세션을 닫는 일은 절대 하지 마십시오.
테스트 자체가 규율입니다. 기존 세션을 열어 둔 채 두 번째 세션을 열고, 새 규칙이 적용된 상태에서 새로 로그인하십시오. 두 번째 로그인이 성공하면 변경은 안전하고 첫 번째 세션을 닫아도 됩니다. 실패하면 열려 있는 세션이 귀환 경로가 되며, 파일을 되돌리고 다시 로드할 수 있습니다. 물리적으로 닿을 수 없는 서버에서는 변경을 한 번에 하나씩 해야 하는 이유도 여기에 있습니다. 깨진 키 파일과 비활성화된 비밀번호 방식을 같은 편집에 넣으면 돌아갈 길이 전혀 남지 않습니다. 감사 도구는 여러분의 파일을 바탕으로 강화된 버전을 출발점으로 만들 수 있지만, 그것은 Match 블록마다 검토하고 sshd -t로 테스트해야 할 초안이지, 검토 없이 투입할 파일이 결코 아닙니다.