SSH StrictModes, 에이전트 포워딩(ssh -A)과 ssh -a 완벽 정리

짧은 답변: `StrictModes yes`(OpenSSH 기본값)는 sshd가 키를 받아들이기 전에 홈 디렉터리, `~/.ssh`, `~/.ssh/authorized_keys`의 소유권과 권한을 확인하게 하며, 그중 하나라도 그룹이나 다른 사용자가 쓸 수 있거나 다른 사용자 소유라면 “Authentication refused: bad ownership or modes”와 함께 로그인을 거부합니다. 검사를 끄지 말고 권한을 고치세요. `ssh -A`를 통한 에이전트 포워딩은 접속해 있는 동안 원격 호스트가 당신의 로컬 키를 사용할 수 있게 하므로, 완전히 신뢰하지 않는 호스트에서는 피하고 대신 `ssh -J`(ProxyJump)를 사용하세요. 소문자 `ssh -a`는 에이전트 포워딩을 명시적으로 비활성화합니다.

이 가이드는 SSH 강화 가이드를 보완하며, Debian 12/13, Ubuntu 24.04, 그리고 AlmaLinux 9와 Rocky 9 같은 RHEL 계열 시스템에 적용됩니다.

SSH StrictModes가 확인하는 것

StrictModes는 `/etc/ssh/sshd_config`의 서버 측 설정입니다. 목적은 간단합니다. 다른 사용자가 당신의 `authorized_keys`에 쓸 수 있다면 자신의 키를 추가해 당신으로 로그인할 수 있습니다. 그래서 sshd는 전체 경로가 보호되지 않으면 그 파일을 신뢰하지 않습니다. 파일과 홈 디렉터리를 포함한 상위 디렉터리를 확인합니다.

실제 적용 값은 `sshd -T | grep -i strictmodes`로 확인하세요. Ubuntu 24.04와 Debian 13에서는 `/etc/ssh/sshd_config.d/`의 드롭인 파일도 확인하세요.

“Authentication refused: bad ownership or modes” 해결하기

클라이언트에는 일반적인 `Permission denied (publickey)`만 표시됩니다. 진짜 이유는 서버 로그에 있으며, `Authentication refused: bad ownership or modes for directory /home/alice` 또는 `... for file /home/alice/.ssh/authorized_keys`처럼 정확한 경로가 나옵니다. VPS 콘솔이나 다른 세션을 이용해 고치세요.

1. 01.로그를 읽으세요: Debian과 Ubuntu에서는 `journalctl -u ssh -n 50`, AlmaLinux와 Rocky에서는 `journalctl -u sshd -n 50`.
2. 02.사용자 SSH 디렉터리의 소유권을 고치세요: `chown -R alice:alice /home/alice/.ssh`.
3. 03.모드를 고치세요: `chmod 700 /home/alice/.ssh`와 `chmod 600 /home/alice/.ssh/authorized_keys`.
4. 04.홈 디렉터리에서 그룹 및 전체 쓰기 권한을 제거하세요: `chmod go-w /home/alice`.
5. 05.SELinux 시스템(AlmaLinux, Rocky, Fedora)에서는 레이블을 복원하세요: `restorecon -Rv /home/alice/.ssh`.
6. 06.작동하는 세션을 열어 둔 채 새 터미널에서 `ssh -v alice@server`로 테스트하세요.

# all-in-one, run as root on the server
chown -R alice:alice /home/alice/.ssh
chmod go-w /home/alice
chmod 700 /home/alice/.ssh
chmod 600 /home/alice/.ssh/authorized_keys
namei -l /home/alice/.ssh/authorized_keys   # shows owner and mode of every path component

Note · 오류를 없애려고 `StrictModes no`를 설정하지 마세요. 실제 보호 장치를 제거하고, 잘못된 설정을 고치는 대신 숨길 뿐입니다.

StrictModes vs StrictHostKeyChecking

“ssh strictmode” 검색에서는 서로 무관한 두 옵션이 자주 혼동됩니다. `StrictModes`는 서버의 `sshd_config`에 있으며 파일 권한을 확인합니다. `StrictHostKeyChecking`은 클라이언트의 `ssh_config` 또는 `~/.ssh/config`에 있으며 서버의 호스트 키를 모르거나 바뀌었을 때의 동작을 제어합니다. 클라이언트에도 자체 권한 검사가 있습니다. 다른 사용자가 읽을 수 있는 개인 키는 보호되지 않은 개인 키 파일이라는 경고와 함께 사용을 거부하며, `chmod 600 ~/.ssh/id_ed25519`로 해결됩니다.

ssh -A 에이전트 포워딩의 위험

`ssh -A`(또는 `ForwardAgent yes`)는 원격 호스트에 `$SSH_AUTH_SOCK`으로 참조되는 소켓을 만들고, 서명 요청을 당신 머신의 ssh-agent로 중계합니다. 개인 키는 절대 당신의 머신을 떠나지 않지만, 그 소켓에 접근할 수 있는 사람은 누구나 당신이 접속해 있는 동안 당신의 키를 사용할 수 있습니다. 원격 호스트에서는 root와 당신의 사용자로 실행되는 모든 프로세스가 여기에 포함됩니다.

서버가 침해되었거나 다른 사람이 관리한다면, 공격자는 Git 호스팅과 프로덕션 서버를 포함해 당신의 키로 열리는 다른 모든 호스트에 조용히 로그인할 수 있습니다. 그래서 OpenSSH 클라이언트의 기본값이 `ForwardAgent no`입니다.

• ▹공유 호스트, 제3자 호스트, 아직 강화하지 않은 새로 재설치한 호스트에는 절대 에이전트를 포워딩하지 마세요.
• ▹꼭 포워딩해야 한다면 `ssh-add -c`를 사용해 키를 쓸 때마다 로컬 확인을 요구하게 하세요.
• ▹OpenSSH 8.9 이상은 `ssh-add -h`로 대상 제한을 지원해, 포워딩된 키를 사용할 수 있는 호스트를 제한합니다.
• ▹서버 측에서는 `sshd_config`의 `AllowAgentForwarding no`로 비활성화할 수 있지만, 셸 접근 권한이 있는 사용자는 여전히 자체 포워더를 만들 수 있습니다.

배스천에는 ProxyJump(ssh -J)를 선호하세요

에이전트 포워딩은 대부분 배스천을 거쳐 내부 머신으로 건너가는 데 쓰입니다. `ssh -J`는 에이전트를 노출하지 않고 이를 해냅니다. 배스천은 암호화된 TCP 스트림만 전달하고, 내부 호스트에 대한 인증은 당신의 노트북에서 종단 간으로 이루어집니다. 사설 네트워크로만 접근 가능한 서버에는 WireGuard 터널도 선택지입니다. WireGuard VPN 가이드나 WireGuard 메시 가이드를, keepalive와 PSK 설정은 WireGuard 튜닝 가이드를 참고하세요.

NoctisNode VPS에서는 KVM 머신에서 SSH로 전체 root 권한을 얻으므로, 작은 Wisp 요금제를 다른 것은 아무것도 실행하지 않는 전용 점프 호스트로 쓸 수 있습니다. VPS 요금제를 참고하세요.

# one-off
ssh -J [email protected] [email protected]

# ~/.ssh/config
Host bastion
    HostName bastion.example.com
    User alice
    ForwardAgent no

Host db1
    HostName 10.88.0.3
    User alice
    ProxyJump bastion

ssh -a(소문자)의 역할

소문자 `ssh -a`는 해당 연결의 에이전트 포워딩을 비활성화하며, `-A`의 반대입니다. `~/.ssh/config`에서 와일드카드 호스트에 `ForwardAgent`를 활성화해 두었는데 특정 연결만은 포워딩하지 않도록 확실히 하고 싶을 때 유용합니다. 예: `ssh -a admin@untrusted-host`. 에이전트 소켓의 경로를 설정하는 `ssh-agent -a`나, 키를 에이전트에 불러오는 `ssh-add`와 혼동하지 마세요.

FAQ