SSH: ключи, конфиг и туннели

Инструмент, через который проходит вся работа с серверами, — и три вещи, которые в нём стоит настроить один раз.

Ключи вместо паролей

Пароль можно подобрать, подсмотреть и забыть. Ключевая пара — нет: приватный ключ лежит у вас, публичный — на сервере, и сервер проверяет подпись, не видя секрета.

ssh-keygen -t ed25519 -C "work laptop"   # создаёт ~/.ssh/id_ed25519{,.pub}
ssh-copy-id user@server                  # кладёт публичный ключ на сервер

ed25519 — современный дефолт: короткие ключи, быстрая проверка. RSA нужен только для очень старых систем.

Права на файлы — не формальность: SSH откажется использовать приватный ключ, доступный кому-то кроме владельца.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519

~/.ssh/config

Всё, что вы набираете в команде ssh дважды, должно жить в конфиге:

Host prod
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519

Host db-internal
    HostName 10.0.3.7
    ProxyJump prod

Теперь ssh prod вместо ssh -i ~/.ssh/id_ed25519 deploy@203.0.113.10, а ssh db-internal сам пройдёт через бастион: ProxyJump — штатный способ добраться до машин без публичного адреса.

Туннели

SSH умеет пробрасывать порты — этим закрывается половина «как посмотреть то, что доступно только с сервера»:

ssh -L 5432:localhost:5432 prod    # localhost:5432 → Postgres на сервере
ssh -L 3000:10.0.3.7:3000 prod     # через prod к внутренней машине

Пока туннель открыт, локальные инструменты (psql, браузер, GUI-клиент) работают с удалённым сервисом как с локальным — без открытия портов наружу.

known_hosts и «кто на том конце»

При первом подключении SSH показывает отпечаток сервера и запоминает его. Если позже отпечаток изменился — SSH громко откажется подключаться. Чаще всего это пересозданный сервер, но именно так выглядела бы и подмена хоста, поэтому предупреждение нельзя глушить не глядя: сначала убедитесь, что сервер действительно пересоздавали.