SSH StrictModes, przekazywanie agenta (ssh -A) i ssh -a — wyjaśnienie

Krótko: `StrictModes yes` (domyślne w OpenSSH) sprawia, że sshd przed zaakceptowaniem klucza sprawdza właściciela i uprawnienia Twojego katalogu domowego, `~/.ssh` i `~/.ssh/authorized_keys`, i odmawia logowania z komunikatem "Authentication refused: bad ownership or modes", jeśli któryś z nich jest zapisywalny dla grupy lub innych albo należy do innego użytkownika. Napraw uprawnienia, zamiast wyłączać kontrolę. Przekazywanie agenta przez `ssh -A` pozwala zdalnemu hostowi używać Twoich lokalnych kluczy, dopóki jesteś połączony, więc unikaj go na hostach, którym nie ufasz w pełni, i zamiast tego używaj `ssh -J` (ProxyJump); małe `ssh -a` jawnie wyłącza przekazywanie agenta.

Ten poradnik uzupełnia poradnik o hardeningu SSH i dotyczy Debiana 12/13, Ubuntu 24.04 oraz systemów z rodziny RHEL, takich jak AlmaLinux 9 i Rocky 9.

Co sprawdza SSH StrictModes

StrictModes to ustawienie po stronie serwera w `/etc/ssh/sshd_config`. Jego cel jest prosty: jeśli inny użytkownik mógłby zapisywać do Twojego `authorized_keys`, mógłby dodać własny klucz i logować się jako Ty. Dlatego sshd odmawia zaufania plikowi, jeśli cała ścieżka nie jest chroniona. Sprawdza plik i katalogi nad nim, łącznie z katalogiem domowym.

Potwierdź obowiązującą wartość przez `sshd -T | grep -i strictmodes`. W Ubuntu 24.04 i Debianie 13 sprawdź też pliki drop-in w `/etc/ssh/sshd_config.d/`.

Naprawa błędu "Authentication refused: bad ownership or modes"

Klient pokazuje tylko ogólny komunikat `Permission denied (publickey)`. Prawdziwa przyczyna jest w logu serwera, który podaje dokładną ścieżkę, na przykład `Authentication refused: bad ownership or modes for directory /home/alice` lub `... for file /home/alice/.ssh/authorized_keys`. Napraw to przez konsolę VPS lub inną sesję.

1. 01.Przeczytaj log: `journalctl -u ssh -n 50` w Debianie i Ubuntu lub `journalctl -u sshd -n 50` w AlmaLinux i Rocky.
2. 02.Popraw właściciela katalogu SSH użytkownika: `chown -R alice:alice /home/alice/.ssh`.
3. 03.Popraw uprawnienia: `chmod 700 /home/alice/.ssh` i `chmod 600 /home/alice/.ssh/authorized_keys`.
4. 04.Usuń prawo zapisu dla grupy i wszystkich z katalogu domowego: `chmod go-w /home/alice`.
5. 05.W systemach z SELinux (AlmaLinux, Rocky, Fedora) przywróć etykiety: `restorecon -Rv /home/alice/.ssh`.
6. 06.Przetestuj z nowego terminala przez `ssh -v alice@server`, zostawiając działającą sesję otwartą.

# 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 · Nie ustawiaj `StrictModes no`, żeby pozbyć się błędu. To usuwa realną ochronę i ukrywa błędną konfigurację zamiast ją naprawić.

StrictModes a StrictHostKeyChecking

Wyszukiwania „ssh strictmode” często mieszają dwie niezwiązane opcje. `StrictModes` znajduje się w `sshd_config` na serwerze i sprawdza uprawnienia plików. `StrictHostKeyChecking` znajduje się w `ssh_config` lub `~/.ssh/config` na kliencie i określa, co się dzieje, gdy klucz hosta serwera jest nieznany lub się zmienił. Klient ma też własną kontrolę uprawnień: odmawia użycia klucza prywatnego, który mogą czytać inni użytkownicy, z ostrzeżeniem o niechronionym pliku klucza prywatnego; naprawia to `chmod 600 ~/.ssh/id_ed25519`.

Przekazywanie agenta przez ssh -A: ryzyko

`ssh -A` (lub `ForwardAgent yes`) tworzy na zdalnym hoście gniazdo, wskazywane przez `$SSH_AUTH_SOCK`, które przekazuje żądania podpisu z powrotem do ssh-agent na Twojej maszynie. Twój klucz prywatny nigdy nie opuszcza Twojego komputera, ale każdy, kto ma dostęp do tego gniazda, może używać Twojego klucza, dopóki jesteś połączony. Na zdalnym hoście oznacza to roota i każdy proces działający jako Twój użytkownik.

Jeśli serwer zostanie przejęty lub administruje nim ktoś inny, atakujący może po cichu zalogować się na każdy inny host, który otwiera Twój klucz, łącznie z hostingiem Git i serwerami produkcyjnymi. Dlatego klient OpenSSH domyślnie ma `ForwardAgent no`.

• ▹Nigdy nie przekazuj agenta na hosty współdzielone, należące do osób trzecich lub świeżo przeinstalowane, których nie zabezpieczyłeś.
• ▹Jeśli musisz przekazywać, użyj `ssh-add -c`, aby każde użycie klucza wymagało lokalnego potwierdzenia.
• ▹OpenSSH 8.9 i nowsze obsługują ograniczenia celu przez `ssh-add -h`, ograniczając hosty, dla których można użyć przekazanego klucza.
• ▹Po stronie serwera `AllowAgentForwarding no` w `sshd_config` to wyłącza, choć użytkownicy z dostępem do powłoki wciąż mogą skonfigurować własne przekierowania.

Do bastionów wybieraj ProxyJump (ssh -J)

Przekazywanie agenta jest najczęściej używane do przeskoku przez bastion na maszynę wewnętrzną. `ssh -J` robi to bez wystawiania agenta: bastion przekazuje tylko zaszyfrowany strumień TCP, a uwierzytelnianie do hosta wewnętrznego odbywa się end-to-end z Twojego laptopa. Dla serwerów osiągalnych tylko przez sieć prywatną inną opcją jest tunel WireGuard; zobacz poradnik o VPN WireGuard lub poradnik o siatce WireGuard, a ustawienia keepalive i PSK opisuje ten poradnik o dostrajaniu WireGuard.

Na VPS NoctisNode dostajesz pełny root przez SSH na maszynie KVM, więc mały plan Wisp może służyć jako dedykowany jump host, na którym nic innego nie działa; zobacz plany 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

Co robi ssh -a (małe a)

Małe `ssh -a` wyłącza przekazywanie agenta dla danego połączenia — odwrotnie niż `-A`. Przydaje się, gdy Twój `~/.ssh/config` włącza `ForwardAgent` dla hosta z wildcardem, a chcesz mieć pewność, że jedno konkretne połączenie nie przekazuje agenta, na przykład `ssh -a admin@untrusted-host`. Nie myl go z `ssh-agent -a`, które ustawia ścieżkę gniazda agenta, ani z `ssh-add`, które ładuje klucze do agenta.

FAQ