Если вы работаете с Windows и подключаетесь по SSH к серверам, Git-репозиториям или jump-host’ам, главная задача — не просто «положить ключ куда-нибудь», а отделить ежедневное использование, резервную копию и контроль доступа. Для этого удобно связать три вещи: KeePass для парольных фраз и метаданных, GPG для зашифрованных резервных копий и SSH-сертификаты для коротких и проверяемых доступов.
Что именно нужно хранить и где
У SSH-ключа обычно есть несколько частей, и путать их не стоит:
- приватный ключ — файл вроде
id_ed25519_work; его нельзя отдавать; - публичный ключ — файл
id_ed25519_work.pub; его можно передавать серверам; - парольная фраза — защищает приватный ключ при использовании;
- SSH-сертификат — файл
id_ed25519_work-cert.pub; это не HTTPS-сертификат, а подписанный центром доступ с ограниченным сроком; - ключ центра сертификации — если вы сами выдаёте SSH-сертификаты, это уже уровень инфраструктуры, а не обычного ноутбука.
Нормальная схема выглядит так: приватный ключ лежит на диске с парольной фразой, парольная фраза хранится в KeePass, резервная копия приватного ключа зашифрована через GPG, а доступ на серверы по возможности выдаётся SSH-сертификатом с коротким сроком жизни.
| Что храним | Где держать | Зачем | На что обратить внимание |
|---|---|---|---|
| Публичный SSH-ключ | В KeePass, в репозитории, в тикете или на сервере | Для добавления доступа | Не секрет, можно спокойно передавать |
| Приватный SSH-ключ | На локальном диске, защищённый парольной фразой | Для ежедневного входа | Не хранить в открытом виде в облаке и чатах |
| Парольная фраза | KeePass или KeePassXC | Чтобы не держать её в голове и не писать в файл | Лучше не включать автоподстановку на чужих или заражённых машинах |
| Резервная копия ключа | GPG-шифрованный файл в KeePass, офлайн-носителе или защищённом облаке | Чтобы восстановиться после замены ноутбука | Проверяйте восстановление хотя бы раз в несколько месяцев |
| SSH-сертификат пользователя | Рядом с ключом, файл -cert.pub |
Для временного доступа на серверы | Сам сертификат не секрет, но должен иметь короткий срок действия |
| Закрытый ключ CA | Отдельная машина, офлайн-хранилище или аппаратный токен | Для подписи SSH-сертификатов | Не должен лежать на обычном рабочем ноутбуке |
Начните с правильного ключа
Для большинства случаев на Windows сейчас нет причины создавать старые RSA-ключи на 1024 бит или DSA. Берите Ed25519, задавайте парольную фразу и сразу добавляйте понятный комментарий, чтобы через год не гадать, для чего этот ключ.
Пример создания ключа в PowerShell:
ssh-keygen -t ed25519 -a 100 -f "$env:USERPROFILE\.ssh\id_ed25519_work" -C "work-laptop-2026"Параметр -a 100 увеличивает число раундов обработки парольной фразы. Это не магия, но делает подбор чуть менее приятным для атакующего. Парольную фразу не выбирайте в стиле Company2024!. Лучше длинная фраза, которую KeePass может хранить за вас.
Отдельно проверьте отпечаток ключа:
ssh-keygen -lf "$env:USERPROFILE\.ssh\id_ed25519_work.pub"Этот отпечаток стоит сохранить в KeePass вместе с самим ключом. Когда будете добавлять публичный ключ на новый сервер или проверять подозрительную замену, сравнение отпечатков экономит нервы.
KeePass: хранить парольную фразу, а не беспорядок
Под KeePass здесь можно понимать KeePass 2.x, KeePassXC или совместимый клиент с защищённой базой. Для SSH удобнее KeePassXC, потому что там есть встроенная работа с SSH Agent. В классическом KeePass это тоже возможно, но часто через плагины.
В KeePass я бы заводил не просто запись «SSH», а нормальную карточку ключа:
- название: SSH key — work laptop — id_ed25519_work;
- парольная фраза: в поле Password;
- примечание: где используется, кто владелец, дата создания, отпечаток;
- вложение: публичный ключ
.pub; - отдельно: путь к GPG-резервной копии, если она есть.
Приватный ключ как вложение в KeePass — спорное решение. Если база KeePass сильная, лежит на зашифрованном диске и не открывается на чужих машинах, это допустимо для аварийной копии. Но для ежедневной работы практичнее хранить сам ключ на диске, а в KeePass держать парольную фразу и метаданные. Тогда даже если кто-то найдёт файл ключа, без парольной фразы он останется почти бесполезным.
Если используете KeePassXC с SSH Agent, включите логику «удалить ключ из агента при закрытии или блокировке базы». Это удобно: база закрыта — агент пустой. База открыта — можно работать. Не стоит оставлять ключи в Pageant или ssh-agent навсегда, особенно на ноутбуке, который бывает в командировках, кафе и общих офисах.
GPG: для резервной копии, а не вместо парольной фразы
GPG не заменяет парольную фразу SSH-ключа. Он решает другую задачу: позволяет сделать резервную копию приватного ключа в виде файла, который нельзя прочитать без отдельного ключа или парольной фразы GPG.
Самый простой вариант для одного пользователя — симметричное шифрование:
gpg --symmetric --cipher-algo AES256 --output id_ed25519_work.gpg id_ed25519_workПосле этого у вас появится id_ed25519_work.gpg. Его уже можно положить в KeePass как вложение, на офлайн-флешку или в защищённое облако. Но пароль к этому GPG-файлу не должен быть написан рядом с ним. Его можно хранить в KeePass, а для аварийного восстановления — ещё и отдельно, например в запечатанном конверте или офлайн-менеджере.
Если вы уже используете GPG-ключи, можно шифровать резервную копию на публичный GPG-ключ:
gpg --encrypt --recipient YOUR_KEY_ID --output id_ed25519_work.gpg id_ed25519_workНо тут есть нюанс: если приватный GPG-ключ был только на этом ноутбуке и ноутбук умер, зашифрованная резервная копия тоже может стать проблемой. Для восстановления лучше иметь офлайн-копию GPG-ключа или отдельный recovery-ключ.
После создания GPG-копии проверьте, что она реально распаковывается:
gpg --decrypt id_ed25519_work.gpgЕсли всё работает, временную незашифрованную копию удалите. На SSD полноценное «затирание» файла не гарантируется, поэтому основной упор делайте не на безопасное удаление, а на шифрование диска: BitLocker, корпоративное шифрование или хотя бы надёжную парольную защиту учётной записи Windows.
SSH-сертификаты: как сделать доступ временным
Обычный публичный ключ на сервере живёт до тех пор, пока вы его не удалите. Это неудобно в компаниях: сотрудник сменил роль, уволился, но ключ всё ещё где-то лежит в authorized_keys. SSH-сертификаты решают эту проблему.
Сертификат не является секретом. Это публичный файл, который говорит серверу: «этот SSH-ключ подписан доверенным центром, может войти как такой-то пользователь и только до такого-то времени».
Пример выдачи пользовательского сертификата на отдельной CA-машине:
ssh-keygen -s ca_user_key -I alice-work-2026-05-15 -n alice -V +12h id_ed25519_work.pubПосле этого появится файл id_ed25519_work-cert.pub. Его нужно положить рядом с приватным ключом. OpenSSH сам подхватит сертификат, если имена совпадают.
На сервере настраивается доверие к публичному ключу центра. Для Linux это обычно /etc/ssh/sshd_config:
TrustedUserCAKeys /etc/ssh/ca/user_ca.pubДля Windows OpenSSH Server путь будет примерно такой:
TrustedUserCAKeys C:/ProgramData/ssh/administrators_ca.pubВот где нужна дисциплина. Закрытый ключ CA нельзя держать на том же ноутбуке, где вы работаете с почтой, браузером и мессенджерами. Его место — отдельная машина, офлайн-хранилище или аппаратный токен. Если украли CA-ключ, злоумышленник может подписывать сертификаты от вашего имени.
Сроки действия лучше делать короткими:
- разработчику на каждый день — 8–24 часа;
- администратору для разовой операции — 1–4 часа;
- CI/CD-задаче — минуты или часы;
- сервисному аккаунту — дольше, но с мониторингом и отдельным владельцем.
Не выдавайте SSH-сертификаты на месяцы «чтобы не возиться». Тогда вы просто перенесёте старую проблему authorized_keys в другую форму.
Особенности Windows: agent, WSL и PuTTY
На Windows SSH-ключи часто живут в нескольких мирах сразу: PowerShell, Git Bash, WSL, PuTTY/Pageant, VS Code, терминалы JetBrains. Отсюда большинство проблем.
Если используете штатный