Шифрование данных: SSH и GnuPG [110.3]

[Sergey_Sysadmin]

Урок 40. Шифрование данных: SSH и GnuPG

Администратор каждый день решает две разные задачи защиты. Первая - безопасно зайти на удалённую машину и что-то на ней сделать: тут работает OpenSSH. Вторая - защитить сами данные (файл, письмо, релиз) так, чтобы их нельзя было прочитать или подделать в пути и в покое: тут работает GnuPG. Обе технологии стоят на асимметричной криптографии (пара ключей), но применяют её по-разному. В этом уроке разберём, как устроен вход по ключу, агент ключей, проброс портов и копирование файлов, как закалить sshd, а потом - как GPG шифрует, подписывает и как работает доверие к чужим ключам.



Как это работает

В асимметричной паре есть закрытый ключ (приватный, держим в секрете) и открытый (публичный, раздаём всем). Что зашифровано открытым - расшифровывается только закрытым, и наоборот. На этом стоит всё: и SSH, и GPG.

SSH сначала договаривается о сессионном симметричном ключе через обмен Диффи-Хеллмана - им и шифруется весь трафик, потому что симметрика быстрее. А пара ключей нужна на этапе аутентификации. При входе по ключу сервер берёт ваш публичный ключ из authorized_keys, шлёт случайный вызов, а ваш клиент доказывает, что владеет соответствующим приватным ключом, не передавая его по сети. Пароль при этом не нужен и не летит никуда.

Отдельно сервер доказывает клиенту, что он - это он. При первом соединении его host-ключ записывается в known_hosts. Если потом отпечаток сменился - ssh громко предупредит: либо сервер переустановили, либо это атака посредника.

GnuPG (gpg) - реализация стандарта OpenPGP. Чтобы зашифровать файл для адресата, gpg генерирует одноразовый сеансовый ключ, шифрует им данные симметрично, а сам сеансовый ключ кладёт рядом, зашифровав открытым ключом получателя. Расшифровать сеансовый ключ может только владелец закрытого ключа - он и читает файл. Подпись работает зеркально: gpg считает хеш данных и шифрует его вашим закрытым ключом; любой вашим открытым ключом проверит, что подпись ваша и содержимое не менялось. Шифрование даёт конфиденциальность, подпись - подлинность и целостность; это разные вещи.

Команды и примеры

Генерация SSH-ключа. В 2026 по умолчанию берём Ed25519 - короткий, быстрый, стойкий:

Код: Выделить всё

ssh-keygen -t ed25519 -C "ivan@laptop-2026"
# приватный ~/.ssh/id_ed25519 (chmod 600), публичный id_ed25519.pub

Раскладка прав в ~/.ssh строгая: каталог 700, приватные ключи 600, иначе sshd и ssh откажутся работать. Закинуть свой публичный ключ на сервер:

Код: Выделить всё

ssh-copy-id -i ~/.ssh/id_ed25519.pub ivan@server
# или вручную: добавить строку .pub в ~/.ssh/authorized_keys на сервере

Агент держит расшифрованный приватный ключ в памяти, чтобы не вводить парольную фразу каждый раз:

Код: Выделить всё

eval "$(ssh-agent -s)"   # запустить агент
ssh-add ~/.ssh/id_ed25519 # добавить ключ (спросит passphrase один раз)
ssh-add -l                 # что в агенте
ssh-add -t 3600 ~/.ssh/id_ed25519  # держать ключ только час

Проброс портов - туннели поверх SSH. Локальный (-L): открыть порт у себя, трафик уходит на сервер и дальше. Удалённый (-R): открыть порт на сервере, трафик возвращается к вам. Динамический (-D): SOCKS-прокси:

Код: Выделить всё

ssh -L 5433:127.0.0.1:5432 ivan@server   # к удалённой БД через localhost:5433
ssh -R 8080:127.0.0.1:80 ivan@server     # отдать свой локальный сайт на сервер
ssh -D 1080 ivan@server                  # SOCKS5-прокси на localhost:1080

Копирование файлов. scp прост, sftp интерактивен; rsync поверх ssh удобнее для больших объёмов:

Код: Выделить всё

scp -r ./build ivan@server:/var/www/   # рекурсивно каталог
sftp ivan@server                        # get/put/ls внутри
rsync -avz -e ssh ./build ivan@server:/var/www/

Hardening sshd. Правки в /etc/ssh/sshd_config (или дроп-ин в sshd_config.d), затем перечитать конфиг через systemd:

Код: Выделить всё

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers ivan deploy
# проверка и перезапуск
sshd -t            # синтаксис конфига
systemctl reload sshd   # Debian/Ubuntu: служба ssh, RHEL/Fedora: sshd

В Debian/Ubuntu служба и сокет называются ssh, в RHEL/Fedora - sshd; имена не путать. Пакет: apt install openssh-server против dnf install openssh-server.

GnuPG. Создание пары, экспорт, шифрование и подпись:

Код: Выделить всё

gpg --full-generate-key          # выбрать тип, размер, срок
gpg --list-keys ; gpg --list-secret-keys
gpg --export -a ivan@mail.ru > ivan.pub.asc   # отдать публичный ключ
gpg --import bob.pub.asc          # импортировать чужой
# зашифровать для Боба и подписать своим ключом
gpg -se -r bob@mail.ru secret.tar
# расшифровать (gpg сам поймёт по заголовку)
gpg -d -o secret.tar secret.tar.gpg
# отдельная отделённая подпись релиза
gpg --detach-sign -a release.tar.gz   # создаст release.tar.gz.asc
gpg --verify release.tar.gz.asc release.tar.gz

Доверие к ключу - это ваша оценка, что ключ реально принадлежит заявленному человеку. Проверяют по отпечатку (fingerprint) по доверенному каналу, затем подписывают:

Код: Выделить всё

gpg --fingerprint bob@mail.ru
gpg --sign-key bob@mail.ru        # вы заверили, что ключ Боба настоящий

gpg-agent кеширует парольную фразу к секретному ключу (аналог ssh-agent) и запускается автоматически.

Частые грабли

• Слишком открытые права на ~/.ssh или приватный ключ (group/other-доступ) - sshd молча игнорирует ключ, вход откатывается на пароль.
• Выключили PasswordAuthentication, не проверив, что ключ реально работает - и заперли себя снаружи. Сначала тестируйте вход по ключу во втором окне, потом отключайте пароль.
• Правки sshd_config перекрываются файлами в sshd_config.d - на современных системах дроп-ины читаются и могут переопределять основной файл; всегда смотрите итог через sshd -T.
• Путают -L и -R. -L открывает порт на вашей машине, -R - на удалённой; перепутали направление - туннель не туда.
• Подписали данные, но думали что зашифровали. Подпись не скрывает содержимое. Для секретности нужен именно -e (--encrypt), а -s это только подпись.
• Потеряли парольную фразу или сам секретный ключ GPG без отзывного сертификата - зашифрованное вами уже не вернуть. Генерируйте revocation certificate сразу при создании ключа.
• Слепо нажали yes на смену host-ключа в known_hosts вместо того чтобы выяснить причину - так пропускают MITM.

Мини-лаба

• На своей машине сгенерируйте ключ ssh-keygen -t ed25519 с парольной фразой и проверьте права в ~/.ssh.
• Скопируйте публичный ключ на тестовый сервер (ssh-copy-id) и войдите по ключу без пароля.
• Запустите ssh-agent, добавьте ключ через ssh-add и убедитесь, что повторный вход не спрашивает passphrase.
• В sshd_config отключите вход root и PasswordAuthentication, проверьте sshd -t и сделайте reload (служба ssh или sshd по дистрибутиву), не закрыв текущую сессию.
• Поднимите туннель ssh -L к какому-нибудь сервису на сервере и достучитесь до него через localhost.
• Создайте пару GPG, зашифруйте файл для самого себя (-e -r), расшифруйте обратно и сравните с оригиналом.
• Сделайте отделённую подпись файла и проверьте её через gpg --verify; затем испортите файл и убедитесь, что проверка падает.

Контрольные вопросы

• Какой файл на сервере и в чьём домашнем каталоге содержит публичные ключи, которым разрешён вход, и какие права на него и на каталог нужны?
• Чем отличается роль known_hosts от authorized_keys и кто кого аутентифицирует с их помощью?
• Что делают опции -L, -R и -D у клиента ssh и на какой машине каждая открывает слушающий порт?
• Зачем нужен ssh-agent и что произойдёт с добавленным ключом после ssh-add -t 600?
• В чём практическая разница между gpg -e и gpg -s, и какая комбинация даёт и секретность, и подлинность?
• Как, имея публичный ключ собеседника, убедиться в его подлинности и зафиксировать это в своём наборе ключей?

[tcp91]

А зачем вообще passphrase на ключ, если он и так лежит у меня на диске под 600? Не двойная ли это перестраховка?

[zfsgeek]

Споткнулся на ровном месте: на ubuntu делал systemctl reload sshd и ругалось unit not found, оказалось служба называется ssh. На centos наоборот sshd. Запомнил теперь.