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 и системам семейства RHEL, таким как AlmaLinux 9 и Rocky 9.

Что проверяет SSH StrictModes

StrictModes — серверная настройка в `/etc/ssh/sshd_config`. Её смысл прост: если другой пользователь может писать в ваш `authorized_keys`, он может добавить свой ключ и войти под вами. Поэтому sshd отказывается доверять файлу, пока не защищён весь путь. Проверяются сам файл и каталоги над ним, включая домашний.

Узнайте действующее значение командой `sshd -T | grep -i strictmodes`. В Ubuntu 24.04 и Debian 13 проверьте также drop-in файлы в `/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.Прочитайте лог: `journalctl -u ssh -n 50` в Debian и Ubuntu или `journalctl -u sshd -n 50` в AlmaLinux и Rocky.
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 и StrictHostKeyChecking

В поисковых запросах «ssh strictmode» часто путают две не связанные опции. `StrictModes` живёт в `sshd_config` на сервере и проверяет права файлов. `StrictHostKeyChecking` живёт в `ssh_config` или `~/.ssh/config` на клиенте и определяет, что происходит, если host-ключ сервера неизвестен или изменился. У клиента есть и собственная проверка прав: он отказывается использовать приватный ключ, который могут читать другие пользователи, с предупреждением о незащищённом файле приватного ключа; это исправляет `chmod 600 ~/.ssh/id_ed25519`.

Проброс агента через ssh -A: в чём риск

`ssh -A` (или `ForwardAgent yes`) создаёт на удалённом хосте сокет, на который указывает `$SSH_AUTH_SOCK`, и через него запросы на подпись идут обратно к ssh-agent на вашей машине. Приватный ключ никогда не покидает ваш компьютер, но любой, кто имеет доступ к этому сокету, может пользоваться вашим ключом, пока вы подключены. На удалённом хосте это root и любой процесс, работающий от вашего пользователя.

Если сервер взломан или им управляет кто-то другой, атакующий может незаметно войти на все остальные хосты, которые открывает ваш ключ, включая Git-хостинг и продакшен-серверы. Именно поэтому клиент OpenSSH по умолчанию использует `ForwardAgent no`.

• ▹Никогда не пробрасывайте агент на общие, сторонние или только что переустановленные хосты, которые вы не укрепили.
• ▹Если пробрасывать необходимо, используйте `ssh-add -c`, чтобы каждое использование ключа требовало локального подтверждения.
• ▹OpenSSH 8.9 и новее поддерживает ограничения по назначению через `ssh-add -h`, ограничивая, для каких хостов можно использовать проброшенный ключ.
• ▹На стороне сервера `AllowAgentForwarding no` в `sshd_config` отключает проброс, хотя пользователи с доступом к shell всё равно могут настроить собственные пересыльщики.

Для бастионов используйте ProxyJump (ssh -J)

Чаще всего проброс агента нужен, чтобы перепрыгнуть через бастион на внутреннюю машину. `ssh -J` делает это, не раскрывая агента: бастион лишь пересылает зашифрованный TCP-поток, а аутентификация на внутреннем хосте идёт сквозняком с вашего ноутбука. Для серверов, доступных только по приватной сети, ещё один вариант — туннель WireGuard; см. руководство по WireGuard VPN или руководство по mesh-сети WireGuard, а про keepalive и PSK — это руководство по тонкой настройке WireGuard.

На VPS NoctisNode у вас полный root по SSH на KVM-машине, так что небольшой тариф Wisp может служить выделенным jump-хостом, на котором больше ничего не работает; см. тарифы 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