시놀로지 SSH를 키 전용으로 바꾼 뒤 포워딩까지 정리한 순서

외부 점검에서 SSH가 기본 포트와 별도 지정 포트 두 곳에 열려 있었습니다

SSH를 키 전용으로 전환하기 전, 외부에서 NAS를 확인했습니다. 공유기 포워딩 때문에 SSH가 기본 포트와 별도로 지정한 포트, 두 곳에서 열려 있었습니다. NAS의 설정 파일만 수정하고 끝낼 일이 아니라는 점을 이 확인에서 알게 됐습니다.

DSM의 자동 차단 기능은 이미 활성화한 상태였습니다. 기준은 24시간 안에 로그인 실패가 3회 발생하면 차단하는 설정입니다. 이 기능은 반복 시도를 줄이는 장치이지만, 포워딩으로 SSH가 외부에 전달되는 상태를 없애지는 않으므로 별도로 다뤘습니다.

설정을 바꾸기 전에는 sshd_config를 백업했습니다. 파일에는 별도 수신 포트를 지정하고, PasswordAuthentication을 no로 바꿔 비밀번호 인증을 끄는 방식으로 수정했습니다. OpenSSH 설정에서 이 항목은 비밀번호 인증 허용 여부를 정합니다.

외부 노출 확인, 서버 인증 설정, 공유기 포워딩은 서로 다른 층의 일입니다. 인증을 키 전용으로 제한해도 포워딩이 남아 있으면 외부 연결 시도 자체는 계속 서버까지 도달합니다. 그래서 전환 작업을 인증 설정과 외부 전달 경로 정리로 나눴습니다.

NAS에서 기본 SSH 수신을 없애지 못해 공유기 포워딩을 삭제했습니다

별도 Port 지시어를 추가했지만 이 NAS의 Synology sshd는 기본 SSH 포트를 함께 수신했습니다. 설정 파일에 별도 포트가 보인다는 사실만으로 기본 수신이 사라졌다고 판단하면 안 되는 상황이었습니다.

기본 SSH 수신을 NAS 내부에서 없애는 대신, 공유기가 NAS로 전달하던 포워딩을 지우는 방향을 택했습니다. NAS가 내부에서 수신 중이더라도 공유기가 해당 연결을 넘기지 않으면 인터넷에서는 연결할 수 없기 때문입니다.

포워딩을 정리한 다음에는 외부 주소로 다시 확인했습니다. 삭제 대상으로 묶은 다섯 항목은 모두 closed였고, 같은 점검에서 웹 서비스 두 항목만 open으로 남았습니다. NAS 내부 설정 화면이 아니라 외부 재측정 결과를 최종 판단값으로 사용했습니다.

포그라운드 재시작과 기존 세션 유지로 설정 적용을 확인했습니다

설정 수정 뒤에는 권한 있는 셸에서 sshd를 포그라운드로 재시작했습니다. 재시작 명령을 백그라운드로 보냈을 때는 권한 있는 셸을 얻기 위해 띄운 임시 컨테이너가 종료되면서 재시작 작업도 함께 끝났습니다.

이 경우 명령이 곧바로 반환됐다는 사실은 적용 완료를 뜻하지 않았습니다. 백그라운드 실행을 피하고, 재시작 명령이 끝날 때까지 같은 셸에서 기다리는 방식으로 바꿨습니다.

PasswordAuthentication no

systemctl restart sshd

sshd 유닛의 KillMode가 process였기 때문에 재시작 뒤에도 이미 연결된 SSH 세션은 끊기지 않았습니다. 기존 세션을 유지한 채 새 터미널에서 새 인증 정책을 시험할 수 있었습니다.

이 순서는 잠금 사고를 줄이는 데도 쓸 수 있었습니다. 새 키 접속이 실패해도 기존 연결에서 설정을 다시 확인하거나 백업본을 되돌릴 수 있으므로, 기존 세션을 먼저 닫을 이유가 없었습니다.

비밀번호 거부와 키 접속 성공을 별도 조건으로 검사했습니다

비밀번호 인증이 실제로 꺼졌는지는 공개키 인증을 제외하고 비밀번호 및 키보드 대화형 인증만 우선하도록 강제해 확인했습니다. 접속 대상에는 클라이언트 설정에 등록한 NAS 별칭을 사용했습니다.

ssh -o PreferredAuthentications=password,keyboard-interactive -o PubkeyAuthentication=no <NAS 별칭> true

이 명령은 Permission denied (publickey).로 끝났습니다. 서버가 제시한 인증 방식은 publickey 하나였고 비밀번호 입력 단계는 나타나지 않았습니다. 설정 파일의 변경이 실제 접속 협상에도 반영됐는지 확인한 결과입니다.

이어서 같은 별칭으로 BatchMode=yes를 적용한 키 인증도 시도했습니다. 이 연결은 정상적으로 이뤄졌고 명령 실행 결과가 출력됐습니다. 비밀번호만 사용한 접속은 거부되고, 등록한 키를 사용한 접속은 통과하는지를 분리해 확인했습니다.

클라이언트 설정에는 호스트 별칭, 대상 주소, 수신 포트, 사용자, 키 파일을 함께 등록했습니다. 이후 접속은 전체 주소를 직접 쓰지 않고 ssh <별칭>으로 통일했습니다. 전체 주소로 접속했을 때 클라이언트가 키를 찾지 못해 비밀번호 입력 창이 나타난 적이 있었기 때문입니다.

키를 잃었을 때는 LAN DSM 화면과 설정 백업으로 되돌립니다

키를 잃어 SSH로 접속하지 못하는 경우에는 LAN에서 DSM 웹 관리 화면에 들어갑니다. 제어판 > 터미널에서 SSH를 껐다가 다시 켜는 방법을 사용할 수 있습니다.

수정 전 백업한 sshd_config를 되돌리는 방법도 남겨 두었습니다. 새 키 접속을 확인하기 전 기존 SSH 세션을 유지한 것은, 문제 발생 시 이 백업을 적용할 경로를 남기기 위해서였습니다.

작업 순서는 외부 노출 확인, 설정 파일 백업, 비밀번호 인증 비활성화, 포그라운드 재시작, 새 창의 비밀번호 거부 검사, 키 접속 검사, 포워딩 삭제 뒤 외부 재측정으로 정리했습니다. 기본 수신이 NAS에서 남아 있더라도 공유기에서 전달하지 않는지까지 확인해야 외부 노출 정리가 끝납니다.