Как перенести SSH-ключи в Bitwarden и перестать хранить приватные ключи в ~/.ssh
SSH-ключи есть почти у каждого разработчика: доступ к серверам, Git-репозиториям, домашней инфраструктуре. Обычно они годами лежат в ~/.ssh, а ssh-agent избавляет от необходимости постоянно вводить парольную фразу. Работает — и ладно. Но со временем возникает вопрос: как контролировать использование ключей и не держать их приватные части в обычных файлах?
Один из вариантов — Bitwarden SSH Agent. Он хранит SSH-ключи в зашифрованном хранилище Bitwarden и выполняет операции подписи от имени SSH-клиента. При этом можно включить отдельное подтверждение использования ключа.
Разберём перенос уже существующего ключа без замены его на серверах. Основной пример — macOS и Fish, ниже есть команды для Zsh и примечания для Linux и Windows.
Важно: Bitwarden не превращает ключ в неэкспортируемый ключ Secure Enclave. Приватный ключ хранится в Bitwarden и может быть экспортирован из хранилища. Touch ID используется для разблокировки приложения, а подтверждение SSH-операции — отдельный запрос. Обязательная биометрия на каждую подпись не гарантируется.
1. Что понадобится
- Установленный Bitwarden Desktop (одного расширения браузера недостаточно для SSH Agent).
- Существующий ключ, например
~/.ssh/id_ed25519, и его публичная часть~/.ssh/id_ed25519.pub. - Доступ к серверу или Git-хостингу, чтобы проверить подключение после переноса.
На macOS Bitwarden можно установить с официального сайта или через Homebrew:
brew install --cask bitwarden
Если Bitwarden уже установлен из Mac App Store, переустанавливать его не нужно — просто учтите, что путь к сокету у этой версии отличается.
2. Находим и проверяем текущий ключ
Просмотрим содержимое каталога:
ls -la ~/.ssh
Приватный ключ — id_ed25519 без .pub. Его нельзя публиковать или отправлять в чат. id_ed25519.pub — публичная часть, которой можно делиться.
Перед импортом запомним отпечаток публичного ключа:
ssh-keygen -lf ~/.ssh/id_ed25519.pub -E sha256
Пока ничего не удаляем. Сначала импортируем ключ, запустим агент и убедимся, что всё работает.
3. Импортируем существующий ключ в Bitwarden
На macOS скопируем приватный ключ в буфер обмена без вывода в терминал:
pbcopy < ~/.ssh/id_ed25519
Теперь в Bitwarden Desktop:
- Нажмите New → SSH key.
- Укажите понятное имя, например
Personal SSH. - Нажмите Import key from clipboard и сохраните запись.
- Сравните публичный ключ и отпечаток в Bitwarden с исходным ключом.
Поддерживаются импортируемые ключи в форматах OpenSSH и PKCS#8; агент работает с Ed25519 и RSA. Если у вас другой формат, сначала проверьте совместимость. Ключи PuTTY .ppk напрямую не импортируются.
Если кнопки импорта нет: в некоторых версиях Bitwarden Desktop встречалась ошибка интерфейса. Попробуйте сначала создать и сохранить новую запись типа SSH key, затем открыть её на редактирование и найти Import key from clipboard там. После импорта обязательно проверьте, что публичный ключ и отпечаток изменились на ожидаемые. Если этого не произошло — импорт не состоялся.
Если исходный ключ защищён passphrase: Bitwarden может запросить её при импорте. У импорта зашифрованных OpenSSH-ключей были известные ошибки: не рассчитывайте, что исходная защита ключевого файла сохранится без изменений. Не снимайте passphrase с оригинального файла ради импорта. При проблемах лучше обновить клиент и проверить импорт на копии либо создать новый ключ.
Сразу очищаем системный буфер обмена:
printf '' | pbcopy
Если у вас включена история буфера обмена в сторонней утилите, удалите секрет и оттуда: команда выше не стирает такую историю.
4. Включаем Bitwarden SSH Agent
В настольном Bitwarden откройте Settings → SSH Agent (название раздела может немного отличаться в зависимости от версии) и включите Enable SSH agent.
В параметре Ask for authorization when using SSH agent выберите Always. Тогда перед использованием ключа Bitwarden будет спрашивать разрешение. Для разблокировки самого хранилища на macOS можно включить Touch ID.
Обратите внимание: Touch ID для разблокировки Vault и запрос Authorize на операцию SSH — не одно и то же.
5. Подключаем агент к терминалу
Bitwarden создаёт локальный сокет, к которому подключается SSH-клиент через переменную SSH_AUTH_SOCK.
macOS + Fish
Для Bitwarden, установленного с сайта или через Homebrew:
set -Ux SSH_AUTH_SOCK "$HOME/.bitwarden-ssh-agent.sock"
Для версии из Mac App Store вместо этого используйте:
set -Ux SSH_AUTH_SOCK "$HOME/Library/Containers/com.bitwarden.desktop/Data/.bitwarden-ssh-agent.sock"
-Ux сохраняет переменную между запусками Fish. Выберите одну команду в соответствии со способом установки.
macOS + Zsh
Добавьте в ~/.zshrc:
export SSH_AUTH_SOCK="$HOME/.bitwarden-ssh-agent.sock"
Для версии из Mac App Store путь будет таким:
export SSH_AUTH_SOCK="$HOME/Library/Containers/com.bitwarden.desktop/Data/.bitwarden-ssh-agent.sock"
Затем примените настройки:
source ~/.zshrc
Проверяем агент
echo "$SSH_AUTH_SOCK"
ssh-add -L
ssh-add -l -E sha256
ssh-add -L показывает публичные ключи, доступные в агенте. Он не импортирует ключи в Bitwarden. Отпечаток из ssh-add -l должен совпасть с отпечатком из шага 2.
Если видите Error connecting to agent: No such file or directory, проверьте, запущен ли Bitwarden, включён ли SSH Agent и существует ли сокет по указанному пути. Если ключей нет, убедитесь, что импорт завершился успешно и хранилище доступно.
6. Проверяем настоящее SSH-подключение
Например, для GitHub:
ssh -T git@github.com
Или для собственного сервера:
ssh user@server.example.com
Когда SSH-клиент попросит использовать ключ, Bitwarden должен показать окно Authorize. Подтвердите запрос и убедитесь, что подключение прошло успешно.
Если ключ уже был зарегистрирован на Git-сервере или в authorized_keys, добавлять его заново не требуется: после импорта это та же самая ключевая пара.
Если в Bitwarden несколько ключей
Чтобы SSH не перебирал все ключи подряд, можно оставить на диске только публичный ключ и указать его в ~/.ssh/config:
Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519.pub
IdentitiesOnly yes
Файл .pub не секретный. SSH использует его, чтобы выбрать соответствующий приватный ключ из Bitwarden SSH Agent.
7. Только теперь убираем старый приватный ключ
Самая важная часть миграции — не удалить единственный рабочий экземпляр.
Сначала убедитесь, что:
- В Bitwarden есть нужный ключ с правильным отпечатком.
ssh-add -Lвидит его через Bitwarden SSH Agent.- Подключение к серверу или Git работает, а запрос подтверждения действительно приходит из Bitwarden.
- Вы продумали восстановление доступа, если Bitwarden станет недоступен.
После проверки перенесите старый приватный файл в защищённую резервную копию и повторите тест уже без локального приватного ключа. Оставьте .pub на месте, если он указан в ~/.ssh/config.
Когда убедитесь, что Bitwarden работает самостоятельно, удалите ненужные локальные копии согласно своей политике резервного копирования. Обычная команда rm на SSD не гарантирует физического уничтожения ранее записанных данных.
8. А что насчёт Linux и Windows?
Linux: для обычной установки Bitwarden через .deb или AppImage чаще используется такой сокет:
export SSH_AUTH_SOCK="$HOME/.bitwarden-ssh-agent.sock"
Добавьте строку в конфигурацию своего shell. У Snap и Flatpak пути отличаются — они перечислены в официальной документации Bitwarden.
Windows: Bitwarden использует совместимый с OpenSSH механизм агента. По инструкции Bitwarden необходимо отключить службу OpenSSH Authentication Agent в services.msc, чтобы избежать конфликта, затем включить агент Bitwarden. Если Git использует собственный ssh.exe, может понадобиться переключить его на системный OpenSSH.
9. Бонус: подписываем Git-коммиты тем же агентом
Bitwarden умеет не только аутентифицироваться на сервере, но и подписывать коммиты. Для Git 2.34+ настройка выглядит так:
git config --global gpg.format ssh
git config --global user.signingkey 'ssh-ed25519 AAAAC3...'
git config --global commit.gpgsign true
В user.signingkey указывается полный публичный ключ из Bitwarden. При создании коммита агент запросит разрешение на подпись. На GitHub или Gitea соответствующий публичный ключ должен быть зарегистрирован для проверки подписей.
Отдельный файл allowed_signers для создания подписей не требуется — он нужен только для локальной проверки доверия к SSH-подписям.
Что получилось — и какие ограничения остались
После переноса SSH-клиент продолжает работать привычным образом, но запросы подписи обрабатывает Bitwarden. Можно управлять ключами в одном хранилище и подтверждать их использование. При этом приватные ключи остаются экспортируемыми и синхронизируемыми между устройствами, а на разблокированном или скомпрометированном компьютере агент не становится абсолютной защитой.
Для максимальной изоляции ключа, привязанного к одному Mac, стоит рассмотреть Secure Enclave с неэкспортируемым ключом. Для повседневной работы на нескольких устройствах Bitwarden SSH Agent — удобный компромисс между управляемостью и безопасностью. В любом случае защищайте сам Bitwarden MFA, используйте автоблокировку и отдельные ключи для разных уровней доступа.