10년 된 노트북으로 비서를 고용하기 (2) — SSH 보안 설정과 Docker 올리기

10년 된 노트북으로 비서를 고용하기

1. 서버 만들기 — 오래된 노트북에 Ubuntu Server 올리기
2. SSH 보안 설정과 Docker — SSH·방화벽 기본과 Docker ← 지금 글
3. Ollama와 n8n 올리기 — 로컬 모델과 자동화 도구
4. 비서 고용 — 외부 접속 경로와 도구를 쓰는 봇

서론

지난 편에서 10년 된 HP 노트북에 Ubuntu Server를 올렸습니다. 덮개를 닫아도 깨어 있고, SSH로 붙을 수 있는 상태까지 왔습니다.

다만 지난 편까지 이 서버는 비밀번호로 접속하고 있었습니다. 집 안에서만 닿으니 당장 문제는 없었지만, 마지막 편에서 외부 접속을 열 예정이라 그 전에 더 견고한 방식으로 바꿔두기로 했습니다.

이번 편에서 하는 일은 두 가지입니다. 서버 접속을 안전하게 제한하는 일과, 다음 편에서 서비스를 올릴 Docker를 준비하는 일입니다. 분량은 앞쪽에 크게 쏠려 있습니다.

그리고 그 과정에서 예상하지 못한 것을 하나 배웠습니다. 설정을 넣는 것보다 그게 실제로 적용됐는지 확인하는 게 어렵습니다. 틀렸을 때 아무도 에러를 내주지 않기 때문입니다.

본론

1. 보안 설정

무엇으로부터 방어하는가?

보안 설정을 하기에 앞서서 생각을 해봤습니다.

“무엇으로부터 방어를 해야하는가?”

이러한 기준이 없으면, 그냥 인터넷 정보나 LLM이 설정해준대로 따라가기만 할 것 같았습니다.

설정하려는 Ubuntu Server는 현재로서는 외부에서 들어올 경로가 없고, 집 안의 네트워크에 연결된 기기 뿐이었으며, 로그인 가능한 사람은 저 혼자였습니다.

물론, 앞으로 외부 네트워크 연결을 하여 비서가 좀 더 많은 일을 할 수 있도록 할 예정이긴 하지만, 초기 셋팅에서는 기본적인 보안 설정으로도 충분하다고 판단했습니다.

그래서 이번 편에서 잡을 것은 세 가지입니다. 전부 SSH로 들어오는 문에 대한 것입니다.

1. 키로만 SSH에 들어가지게 만들기 — 비밀번호 인증을 닫습니다
2. SSH 포트 옮기기 — 기본 포트를 노리는 자동 스캔을 줄입니다
3. fail2ban — 인증 실패가 반복되는 IP를 자동으로 막습니다

방화벽(ufw)은 이번 편에서 다루지 않습니다. 설치는 되어 있지만 켜지 않은 상태 그대로 두었습니다. 무엇을 열어둘지는 무엇을 올릴지가 정해진 다음의 문제라, 외부 접속 경로까지 정해지는 마지막 편에서 함께 손보는 편이 낫다고 판단했습니다.

sudo ufw status

Status: inactive

지금 무엇이 열려 있는지부터

무엇을 잠글지 정하려면 지금 무엇이 열려 있는지를 먼저 알아야 합니다. 그래서 sshd가 실제로 어떤 설정으로 돌고 있는지부터 봤습니다.

여기서 봐야 할 것은 sshd_config 파일의 내용이 아니라 sshd가 그 파일들을 다 읽고 최종적으로 결정한 값입니다. 설정은 여러 파일에 흩어져 있고, 주석 처리되어 아무 효력이 없는 줄도 섞여 있기 때문입니다.

sudo sshd -T | grep -iE 'passwordauth|permitroot|pubkeyauth|maxauthtries'

maxauthtries 6
permitrootlogin no
passwordauthentication yes
pubkeyauthentication yes

passwordauthentication yes. 비밀번호로 들어올 수 있는 상태입니다. 그리고 이건 제가 어딘가에 그렇게 적어둬서가 아니라, 손대지 않으면 그렇게 되어 있는 기본 상태입니다.

집 안에서만 닿는 서버라 당장 위험하진 않지만, 비밀번호는 추측할 수 있는 것입니다. 키는 추측할 수 없습니다. 그래서 첫 작업은 여기입니다.

sudo sshd -t && sudo sshd -T | grep -i passwordauth

1단계 — 키로 접속되게 만들기

키로 접속되게 만들고, 그다음에 비밀번호로 들어오는 것을 차단합니다. 순서를 바꾸면 안 됩니다. 비밀번호를 먼저 닫았는데 키가 제대로 등록되어 있지 않으면, 그 순간부터 들어갈 방법이 없는 서버가 됩니다.

키는 비대칭키 한 쌍으로 만듭니다. 개인키는 접속하는 쪽에 남고 공개키만 서버에 올라가므로, 키를 만드는 곳은 서버가 아니라 접속할 기기입니다. 저는 맥에서 접속하니 맥에서 만들었습니다.

ssh-keygen -t ed25519 -f ~/.ssh/home_ed25519 -C "home-server"

파일 이름을 home_ed25519로 지은 것도 나중을 위한 것입니다. 기본값인 ~/.ssh/id_ed25519로 만들면 키가 여러 개가 됐을 때 어느 것이 어느 서버 것인지 알 수 없게 됩니다. 서버 이름을 파일명에 넣어두면 지우거나 교체할 때 헷갈리지 않습니다. 1편에서 정한 호스트명이 home-server라 home_ed25519로 지었습니다.

만든 공개키를 서버에 등록합니다.

ssh-copy-id -i ~/.ssh/home_ed25519.pub home-server

이 명령이 하는 일은 단순합니다. 서버에 접속해서 ~/.ssh/authorized_keys 끝에 공개키 한 줄을 덧붙이는 것입니다. 이 시점에는 아직 비밀번호로 접속합니다.

cat ~/.ssh/home_ed25519.pub | ssh <사용자 이름>@<서버 고정 IP> \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

그리고 맥의 ~/.ssh/config에 접속 정보를 적어둡니다.

IgnoreUnknown UseKeychain

Host <접속할 서버의 별명(임의 설정 가능)>
  HostName <접속 url 혹은 ip>
  Port <설정한 포트>
  User <사용자 이름>
  IdentityFile ~/.ssh/home_ed25519
  IdentitiesOnly yes
  AddKeysToAgent yes
  UseKeychain yes

Host 뒤의 별명은 마음대로 정하면 됩니다. 저는 1편에서 정한 호스트명을 그대로 따서 home-server로 지었고, 이 글에서 앞으로 나오는 ssh home-server는 전부 이 별명을 부르는 것입니다. 4편에서 외부 접속 경로를 붙일 때도 이 블록을 고쳐 씁니다. 이 블록을 적어두면 ssh -p <SSH 포트> <사용자 이름>@<서버 고정 IP> 대신 ssh home-server로 끝납니다.

IdentitiesOnly yes가 중요합니다. 이게 없으면 SSH는 가지고 있는 키를 순서대로 전부 시도하는데, 서버의 MaxAuthTries에 먼저 걸려서 정작 맞는 키를 내밀기 전에 끊길 수 있습니다. 지정한 키 하나만 쓰게 못박아두는 옵션입니다.

이제 검증합니다.

ssh -o PreferredAuthentications=publickey home-server 'echo KEY_OK'

KEY_OK

여기까지 확인되기 전에는 다음 단계로 넘어가지 않습니다.

/Users/me/.ssh/config: line 20: Bad configuration option: usekeychain

IgnoreUnknown UseKeychain

2단계 — 비밀번호 로그인 닫기

키가 되는 것을 확인했으니 이제 비밀번호를 닫습니다. sshd_config를 직접 고치지 않고 sshd_config.d/에 파일을 하나 추가했습니다.

sudo tee /etc/ssh/sshd_config.d/01-hardening.conf > /dev/null <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
PermitEmptyPasswords no
MaxAuthTries 3
EOF

sudo echo "..." > /etc/ssh/sshd_config.d/01-hardening.conf   # 실패합니다

printf '%s\n' 'PasswordAuthentication no' 'KbdInteractiveAuthentication no' \
  | sudo tee /etc/ssh/sshd_config.d/01-hardening.conf > /dev/null

재시작 전에 문법과 병합 결과를 확인합니다.

sudo sshd -t && sudo sshd -T | grep -iE 'passwordauth|kbdinteractive|maxauthtries'

maxauthtries 3
passwordauthentication no
kbdinteractiveauthentication no

값이 의도대로 나오면 재시작합니다.

sudo systemctl restart ssh

그리고 검증인데, 두 가지를 따로 물어봐야 합니다.

ssh home-server 'echo STILL_OK'                                  # 키가 되는가
ssh -o PreferredAuthentications=password \
    -o PubkeyAuthentication=no home-server true                  # 비밀번호가 막히는가

STILL_OK
Permission denied (publickey).

괄호 안에 publickey만 남았습니다. 이전에는 (publickey,password)였습니다. 첫 번째 명령은 “키가 된다”만 증명하고, “비밀번호가 안 된다”는 두 번째만이 증명합니다.

grep -n "^Include" /etc/ssh/sshd_config

24:Include /etc/ssh/sshd_config.d/*.conf

50-cloud-init.conf   PasswordAuthentication yes   ← 먼저 읽힘. 이김
99-hardening.conf    PasswordAuthentication no    ← 무시됨
01-hardening.conf    PasswordAuthentication no    ← 50보다 앞. 이김

echo 'ssh_pwauth: false' | sudo tee /etc/cloud/cloud.cfg.d/99-ssh-pwauth.cfg

3단계 — SSH 포트 옮기기

기본 포트인 22번은 자동 스캔의 첫 번째 대상입니다. 포트를 옮긴다고 보안이 강해지는 것은 아니지만, 의미 없는 로그와 시도가 크게 줄어듭니다. fail2ban이 진짜 봐야 할 것을 보게 만드는 정리 작업에 가깝습니다.

Ubuntu 24.04부터 sshd는 소켓 활성화(socket activation) 방식으로 돕니다. 데몬이 포트를 잡고 기다리는 게 아니라, systemd가 포트를 열어두고 있다가 접속이 들어오면 그때 sshd 인스턴스를 띄웁니다. 그래서 포트를 결정하는 것은 sshd_config가 아니라 ssh.socket입니다.

sudo systemctl edit ssh.socket

여기에 세 줄을 적습니다.

[Socket]
ListenStream=
ListenStream=<SSH 포트>

중간의 빈 ListenStream=이 핵심입니다. 이 줄이 기본값 22를 지웁니다. 이게 없으면 22와 새 포트를 둘 다 듣게 됩니다.

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

확인은 설정이 아니라 실제로 듣고 있는 쪽을 봐야 합니다.

sudo ss -tulpn | grep <SSH 포트>

LISTEN 0.0.0.0:<SSH 포트>  users:(("sshd",pid=18364,fd=3),("systemd",pid=1,fd=256))

systemd가 함께 잡혀 있는 것이 소켓 활성화의 흔적입니다.

sudo sshd -T | grep '^port'

port <SSH 포트>

systemctl is-enabled ssh.socket   # enabled 면 소켓 활성화

4단계 — fail2ban으로 반복 시도 막기

키만 받도록 잠갔지만, 그래도 누군가는 계속 두드릴 수 있습니다. fail2ban은 로그를 지켜보다가 인증 실패가 정해진 횟수를 넘긴 IP를 방화벽 수준에서 차단합니다.

sudo apt install -y fail2ban

-y는 설치 중간에 나오는 “계속할까요? [Y/n]” 질문에 미리 예라고 답해두는 옵션입니다(yes). 없으면 엔터를 한 번 더 쳐야 합니다.

설정은 jail.d/에 파일을 만들어 넣습니다. jail.conf를 직접 고치면 패키지 업데이트 때 덮어쓰기 때문입니다.

sudo tee /etc/fail2ban/jail.d/sshd.local > /dev/null <<'EOF'
[sshd]
enabled = true
backend = systemd
mode = aggressive
maxretry = 3
findtime = 10m
bantime = 1h
EOF

sudo systemctl restart fail2ban

sudo fail2ban-client set sshd unbanip <내 IP>   # 실수로 자신을 막았을 때

읽는 순서대로 옮기면 10분 안에 3번 실패한 IP를 1시간 차단입니다. backend = systemd는 로그 파일 대신 journald를 읽으라는 뜻이고, Ubuntu처럼 로그가 journal로 가는 환경에서는 이쪽이 맞습니다.

문제는 이 상태의 출력이 이렇게 나온다는 것입니다.

Status for the jail: sshd
|- Currently failed: 0    |- Total failed:  0
`- Currently banned: 0    `- Total banned:  0

전부 0입니다. 그럴듯한 설명이 바로 떠오릅니다. 외부에서 들어올 경로가 없으니 두드릴 사람도 없다. 맞는 말처럼 들리지만, 설정이 아예 안 먹고 있어도 똑같이 0이 나옵니다. 그래서 직접 두드려보기로 했습니다.

두드리기 전에 현재 값을 한 번 찍어둡니다. 그런데 이미 0이 아닙니다.

sudo fail2ban-client status sshd

|- Currently failed: 0    |- Total failed:  4

2단계에서 제가 쌓은 것입니다. 비밀번호가 막히는지 확인하려고 PubkeyAuthentication=no를 붙여 일부러 실패시킨 그 접속들입니다. 저에게는 검증이었지만 fail2ban 입장에서는 구분할 방법이 없는 인증 실패입니다. 로그에 남은 것만 보고 세는 도구라 의도까지는 알지 못합니다.

이 숫자를 미리 확인해두는 것이 검증의 절반입니다. 봐야 하는 것은 값 자체가 아니라 증가분이기 때문입니다. 이제 없는 계정으로 세 번 두드립니다.

for i in 1 2 3; do
  ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no \
      -p <SSH 포트> nosuchuser@<서버 고정 IP> true
done

sudo fail2ban-client status sshd

|- Currently failed: 3    |- Total failed:  7

for i in 1 2 3; do ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no -p <SSH 포트> nosuchuser@<서버 고정 IP> true; done

sudo fail2ban-client get sshd maxretry
sudo fail2ban-client get sshd bantime

4에서 7. 정확히 3이 올랐습니다. fail2ban 자체 로그에도 남았습니다.

fail2ban.filter [sshd] Found <접속하는 기기의 IP> - 2026-08-29 13:27:48
fail2ban.filter [sshd] Found <접속하는 기기의 IP> - 2026-08-29 13:27:48
fail2ban.filter [sshd] Found <접속하는 기기의 IP> - 2026-08-29 13:27:49

0이었던 이유는 정말로 두드릴 사람이 없어서였습니다. 짐작이 맞았지만, 맞았다는 걸 알게 된 건 확인했기 때문입니다.

sudo fail2ban-client get sshd maxretry

여기까지의 상태

2. Docker 설치

공식 저장소로 설치하기

Docker를 설치하는 방법은 세 가지입니다. Ubuntu 기본 저장소의 docker.io, snap, 그리고 Docker가 직접 운영하는 공식 저장소입니다. 저는 공식 저장소를 등록하는 쪽을 골랐습니다.

이유는 이 서버에 931GB HDD가 /data에 붙어 있기 때문입니다. 언젠가 거기에 데이터를 둘 생각인데, snap으로 설치한 Docker는 파일시스템 접근이 격리되어 있어서 홈 디렉터리 밖의 경로를 볼륨으로 마운트할 때 막힙니다. 처음부터 막힐 길로 갈 이유가 없었습니다.

sudo apt update
sudo apt install ca-certificates curl gnupg

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

설치된 버전입니다.

Docker            29.7.2
Docker Compose    v5.5.0

docker compose가 공백인 것에 주의해야 합니다. 예전에 쓰던 docker-compose(하이픈)와 다른 물건입니다.

docker 그룹에 들어간다는 것의 의미

매번 sudo를 붙이기 번거로워서 사용자를 docker 그룹에 넣었습니다.

sudo usermod -aG docker $USER

이 명령은 현재 세션에 바로 반영되지 않습니다. 로그아웃 후 다시 접속해야 합니다.

sudo usermod -G docker $USER    # 위험합니다

groups              # 지금 내가 속한 그룹
id -nG <사용자>     # 특정 사용자의 그룹

permission denied while trying to connect to the Docker daemon socket

groups | grep docker

그런데 이 한 줄에는 대부분의 설치 안내가 적지 않는 사실이 하나 있습니다. docker 그룹에 속한다는 것은 사실상 root 권한을 갖는 것과 같습니다.

# docker 그룹 사용자가 sudo 없이 실행 가능
docker run -it -v /:/host alpine chroot /host sh

호스트의 루트 디렉터리를 컨테이너에 통째로 마운트하고 그 안으로 들어가는 명령입니다. 이 순간부터 호스트 파일시스템 전체를 root 권한으로 읽고 씁니다. Docker 데몬 자체가 root로 돌고 있고, 그 데몬에게 명령할 수 있는 권한이 곧 root 권한이기 때문입니다. 막을 방법은 없습니다. 취약점이 아니라 설계가 그렇습니다.

결론

Ubuntu Server에 보안 설정과 Docker 설치를 했습니다. 이제는 비밀번호로 접속하지 않고, 가지고 있는 키로 간편히 접속할 수 있고, SSH 연결 포트를 변경하여 기본 포트만 노리는 자동 스캔은 헛걸음하게 되었습니다. 그리고 fail2ban이 반복되는 인증 실패를 세고 있습니다.

다음 편에서는 지금까지 만들었던 Ubuntu Server에 Ollama와 n8n을 올려보려고 합니다. 로컬에서 도는 언어 모델과, 그 모델을 정해진 시각에 불러줄 자동화 도구입니다.