SSH 키를 추가하고 비밀번호 인증을 꺼 두기

앉아 있는 기계에서 키 생성하기

서버가 아니다. 비밀 키 절반은 접근 권한을 잃을 수 있는 호스트에 존재해서는 안 되며, 복사해서 옮기면 키의 의미가 사라진다.

ssh-keygen -t ed25519 -a 100 -C "laptop-2026"

-a 100은 암호문구를 보호하는 KDF 라운드 수를 설정하며, 이는 도난당한 노트북과 당신의 서버 fleet 사이에 있는 유일한 보호 장치다. 암호문구를 사용하라. 하드웨어 토큰이 있다면 대신 그것을 사용하라:

ssh-keygen -t ed25519-sk -O resident -C "token-1"

공개 키 절반 설치하기

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@<ipv4>

계정에 아직 비밀번호가 없다면 루트 세션에서 수동으로:

install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
install -m 600 -o deploy -g deploy /dev/null /home/deploy/.ssh/authorized_keys
cat >> /home/deploy/.ssh/authorized_keys

한 줄을 붙여넣고 Ctrl-D를 누르세요. 권한은 사람들이 생각하는 것보다 중요하다. sshd는 그룹 쓰기 가능한 홈 디렉토리나 .ssh 디렉토리를 거부하며, 클라이언트가 아닌 데몬 로그에만 그 이유를 설명한다.

그 안에 있는 동안 키 제한하기

authorized_keys의 옵션은 키별로 적용된다. restrict는 모든 것을 끄고, 그런 다음 키가 실제로 필요한 것만 다시 추가한다:

restrict,pty ssh-ed25519 AAAAC3Nza... deploy@laptop

한 가지 작업을 실행하기 위해 존재하는 키는 한 가지 작업만 실행할 수 있어야 한다:

restrict,command="/usr/local/bin/backup-receive" ssh-ed25519 AAAAC3Nza... backup

잠그기 전에 테스트하기

첫 번째 세션은 연결 상태로 두세요. 두 번째 터미널에서:

ssh -o PreferredAuthentications=publickey deploy@<ipv4> id

uid가 출력되면 키 경로가 작동하는 것이다. 그렇지 않으면 클라이언트의 ssh -vvv과 서버의 journalctl -u ssh -n 50이 어느 쪽이 문제인지 말해 줄 것이다. 대략 절반은 권한 문제이고, 나머지 대부분은 잘못된 사용자 이름이다.

비밀번호 끄기

cat > /etc/ssh/sshd_config.d/20-keys-only.conf <<EOF
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no
AuthenticationMethods publickey
EOF
sshd -t && systemctl reload ssh

AuthenticationMethods publickey은 견고한 보호 장치다. 나중에 드롭인 파일이 조용히 비밀번호를 다시 활성화하더라도 데몬은 키가 아닌 것을 계속 거부한다.

클라이언트에서 문이 닫혔는지 확인하세요:

ssh -o PreferredAuthentications=password deploy@<ipv4>

예상 결과는 Permission denied (publickey)이다.

배포 시 키

패널은 계정별 키 목록을 유지한다. 원하는 키를 선택하면 cloud-init이 첫 부팅 중에 이를 작성하므로, 인스턴스가 처음부터 비밀번호 인증이 꺼진 상태로 존재할 수 있다. 키를 주문에 첨부하면 위의 10분이 1분이 된다.

키를 잃어버렸을 때

여기에는 신원 기반 복구가 없다. 우리는 신원을 보유하지 않기 때문이다. 대역 외 콘솔이 복구 경로이다. 이는 sshd를 거치지 않는 경로로 인스턴스에 도달하며, 구조 셸에서 새 키를 추가하고 계속 진행할 수 있다.

두 번째 기계에 두 번째 키를 보관하면 이 문서를 읽을 일이 없을 것이다.