LINUX.ORG.RU

GPG & SSH keys

 , , ,


1

3

Доброго времени, уважаемые форумчане!
Задался я вопросом: А как вообще правильно хранить GPG и SSH ключи?
Т.е. у меня есть папки

~/.gnupg
~/.ssh

На ум приходят только варианты залить эти папки либо в облако (к примеру Google Drive), либо на Git (приватный аккаунт на GitLab).
Но вопрос безопасности, конечно же, волнует прежде всего.
И опять же, если даже я эти папки залью куда-то в вышеуказанный сервис, то смогу ли я или воспользоваться просто закинув их так же в домашнюю директорию ~/ после, к примеру, переустановки системы или что-то в этом роде?

папки

Мамки.

залить эти папки либо в облако

Приватные ключи? С тем же успехом ты их можешь просто удалить.

либо на Git (приватный аккаунт на GitLab)

Те же яйца.

При выкладывании личных данных они полностью доступны владельцам сервисов. Также никто не отменял дыры и утечки (в том числе намеренные).

Но вопрос безопасности, конечно же, волнует прежде всего.

Хранить бэкап на соседнем/внешнем диске, на флэшке (весит оно совсем ничего) или CD/DVD.

если даже я эти папки залью куда-то в вышеуказанный сервис, то смогу ли я или воспользоваться просто закинув их так же в домашнюю директорию ~/ после, к примеру, переустановки системы или что-то в этом роде?

Да, можешь. Только не забудь про права при развёртывании бэкапа.

mord0d ★★★ ()

А как вообще правильно хранить GPG и SSH ключи?
На ум приходят только варианты залить эти папки либо в облако.

Вот так сущность твоей проблемы более понятна.

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

Выбор ключа для конкретной сессии, как и другие команды по по созданию и удалению ключей должны отдаваться через собственный интерфейс устройства(дисплей и тачскрин видимо), как в устройстве должны быть и собственные источники энтропии и опять таки исключающий возможность получения команд из вне ОТДЕЛЬНЫЙ интерфейс для подключения внешнего источника энтропии.

Учитывая важность устройства и то, что оно будет использоваться долгое время интерфейсы для подключения к нему должны быть устойчивы для механического износа и электрического повреждения, а значит они должны быть оптическими, что-то вроде toslink наверное.

torvn77 ★★★★★ ()
Последнее исправление: torvn77 (всего исправлений: 3)

Зачем их хранить ещё где-то кроме того места, где используешь?

Это какая-то проблема сгенерить новые, если понадобится?

grem ★★★★★ ()
Ответ на: комментарий от grem

Это какая-то проблема сгенерить новые, если понадобится?

Сгенерировать новые не проблема. Проблема будет, если потеряешь доступ к уже имеющимся.

parnyagan ()
Ответ на: комментарий от mord0d

Хранить бэкап на соседнем/внешнем диске, на флэшке

Т.е. я правильно понимаю, что эти папки каталоги я могу просто скопировать на флешку, а в дальнейшем (при необходимости) просто скопировать их с флешки в ~/ ?

parnyagan ()

gpg --export и gpg --import. Если не нравятся облака, то сделай из экспортированного ключа QR-код и распечатай. На арчвики все написано. Потом его легко можно будет отсканировать смартфоном.

отдельные ssh-ключи вообще не нужны - gpg умеет взаимодействовать с openssh и putty.

Lrrr ()

А как вообще правильно хранить GPG и SSH ключи?

В зашифрованном файле-контейнере, например.

Prosto_user ★★ ()
Ответ на: комментарий от parnyagan

Да. Но это в качестве бэкапа, для безопасного хранения существуют смарткарты (работают с GnuPG единицы) и USB-токены (я в их безопасность не верю).

mord0d ★★★ ()
Ответ на: комментарий от parnyagan

Объяснили подробно, да так, что теперь вООбще ничего не понятно…

Объясняю:
Позволить украсть ключи шифррвания это всё равно что выдать доверенность на соответствующие действия от твоего имени человеку который у тебя эти ключи украл, при этом в отличии от доверенности ты даже не будешь знать что эти ключи у тебя украли пока к тебе не придут потребовав исполнения подписанных ключём договоров или компенсации последствий действий заверенных этими ключами.

torvn77 ★★★★★ ()
Последнее исправление: torvn77 (всего исправлений: 2)
Ответ на: комментарий от mord0d

ключ все равно будет защищен паролем, так что какая разница. Да и гугл плевать хотел на это - им нужна статистика, а не секреты.

Плюс, сканировать именно смартфоном не обязательно, (кажется) есть и опенсорсные программы под linux, работающие с веб-камерой.

Lrrr ()
Ответ на: комментарий от Lrrr

ключ все равно будет защищен паролем

Ага, ты ещё в keybase.io не забудь слить свой приватный ключ. Вместе с паролем.

так что какая разница

Если приватный ключ слит (не важно, взломан или нет), его принято отзывать. Имея доступ можно взломать всё. А получив доступ к ключу, можно получить доступ и к остальным данным, которые им шифрованы.

Да и гугл плевать хотел на это - им нужна статистика, а не секреты.

То есть ты доверяешь гуглу. А обосрутся — виноват будешь ты, потому что доверился. Тебе никаких гарантий никто не давал, и ответственность никто нести не будет.

Плюс, сканировать именно смартфоном не обязательно, (кажется) есть и опенсорсные программы под linux, работающие с веб-камерой.

QR — усложнение ради усложнения. Для хранения ключа достаточно --armor, который выплёвывает вполне текстовый base64, который при gzip-сжатии весит совсем ничего и при необходимости импортируется в GnuPG без каких-либо плясок с бубном (и уж тем более без необходимости в каких-то дополнительных железках и девайсах).

mord0d ★★★ ()
Ответ на: комментарий от Lrrr

gpg --export и gpg --import

Тут будут участвовать как публичные, так и приватные ключи?

parnyagan ()
Ответ на: комментарий от grem

Топикстартер только настроил pass, и потеряв gpg-ключ он потеряет доступ ко всем сохранённым паролям.

Так что правильно топикстартер задумывается о бэкапах, только методы выбирает неправильные.

mord0d ★★★ ()
Ответ на: комментарий от Lrrr

отдельные ssh-ключи вообще не нужны

Ну тут кому как… У меня, к примеру, Git настроен на push и pull без ввода пароля через SSH.

parnyagan ()
Ответ на: комментарий от Prosto_user

В зашифрованном файле-контейнере, например

Что за файл-контейнер? Как он у меня сохранится при переустановке ОС? Хранить на флешке? Хранить в облаке? Залить на GIT?

parnyagan ()
Ответ на: комментарий от mord0d

существуют смарткарты… и USB-токены

Простое хранение на флешке где-нибудь в укромном местечке не подойдет? :-)

parnyagan ()
Ответ на: комментарий от torvn77

Объясняю…

Про то, что их надо надежно хранить, в этом я и не сомневался, иначе не создавал бы данную тему.
Вопрос заключается КАК, а не ЗАЧЕМ.

parnyagan ()
Ответ на: комментарий от Lrrr

ключ все равно будет защищен паролем

Тем паролем (фраза-пароль), что запрашивается при обращении какой-либо программы к зашифрованным файлам?
И вы так и не ответили мне в теме на вопрос «можно ли поменять эту фразу-пароль?». ;-)

parnyagan ()
Ответ на: комментарий от parnyagan

Что за файл-контейнер?

Файл, содержащий содержимое в зашифрованном виде по умолчанию. Можно пойти дальше и замаскировать такой контейнер под медиа файл, который можно запустить (и он будет проигрываться), смонтировать и работать с ним как зашифрованным файл-контейнером.

Как он у меня сохранится при переустановке ОС?

Как и любой другой файл, который ты не затираешь при переустановке системы.

Хранить на флешке? Хранить в облаке? Залить на GIT?

Как хочешь.

Prosto_user ★★ ()
Ответ на: комментарий от grem

Не в ту сторону смотрите! Я ищу способ сохранения ключей, а не их блокировки при потере/краже.
Вот чтобы их не потерять и не дать украсть, именно с этой целью и была создана данная тема! Чтобы найти метод надежного хранения.
Флешка / Облако / ГИТ, в каком формате хранить, как восстановить при смене ОС. Вот в чем заключается вопрос!

parnyagan ()
Ответ на: комментарий от mord0d

Так что правильно топикстартер задумывается о бэкапах, только методы выбирает неправильные

Так дайте наставление как и что к чему… ;-)

parnyagan ()
Ответ на: комментарий от Prosto_user

Ок, понял! С cp разобрались. Т.е. я копирую каталоги на флешку

~$ cp -p .ssh/ sda/
~$ cp -p .gnupg/ /sda

*где sda - это флешка.
При этом они будут скопированы с сохранение прав. И так эе в обратном порядке при необходимости?

~$ cp -p sda/.ssh/ ~/
~$ cp -p sda/.gnupg/ ~/

Верно?

parnyagan ()
Ответ на: комментарий от parnyagan

Простое хранение на флешке где-нибудь в укромном местечке не подойдет? :-)

В качестве бэкапа — подойдёт. Для безопасного использования — нет.

mord0d ★★★ ()
Ответ на: комментарий от parnyagan

Монтируешь флэшку например в /media/usbstick, и бэкапишь:

#!/bin/sh
cd ${HOME}/.gnupg
tar -cJpf /mount/usbstick/gnupg-$(date '+%Y-%m-%d').tar.xz .

cd ${HOME}/.ssh
tar -cJpf /mount/usbstick/ssh-$(date '+%Y-%m-%d').tar.xz .

sync

Использование tar сохраняет права на файлы внутри архива.

mord0d ★★★ ()
Ответ на: комментарий от parnyagan

При этом они будут скопированы с сохранение прав.

Только при условии что файловая система на флэшке поддерживает UNIX-права. То есть на FAT или NTFS это не даст результата.

mord0d ★★★ ()
Ответ на: комментарий от mord0d

QR — усложнение ради усложнения. Для хранения ключа достаточно –armor, который выплёвывает вполне текстовый base64, который при gzip-сжатии весит совсем ничего и при необходимости импортируется в GnuPG без каких-либо плясок с бубном (и уж тем более без необходимости в каких-то дополнительных железках и девайсах).

qr-код нужен для хранения ключа на физическом носителе, а не на электронном. Совсем чужие посты не читаем, да?

То есть ты доверяешь гуглу. А обосрутся — виноват будешь ты, потому что доверился. Тебе никаких гарантий никто не давал, и ответственность никто нести не будет.

для обычного пользователя, хранящего в pass пароли от веб-сайтов, такой уровень безопасности вполне достаточен.

Во всех остальных случаях ни одна нормальная фирма не будет полагаться на самодеятельность сотрудников, просящих совета на форумах. А также на gnupg, в которой в разное время находили кучу уязвимостей.

Lrrr ()
Ответ на: комментарий от Lrrr

qr-код нужен для хранения ключа на физическом носителе, а не на электронном.

Бумага — один из самых ненадёжных носителей.

Совсем чужие посты не читаем, да?

Какое мне дело до чужого?

для обычного пользователя, хранящего в pass пароли от веб-сайтов, такой уровень безопасности вполне достаточен.

А потом удивляются, чего это IT скатилось…

Во всех остальных случаях ни одна нормальная фирма не будет полагаться на самодеятельность сотрудников, просящих совета на форумах. А также на gnupg, в которой в разное время находили кучу уязвимостей.

Причём здесь нормальная-ненормальная фирма?

mord0d ★★★ ()
Ответ на: комментарий от mord0d

Какое мне дело до чужого?

тогда зачем нажимаешь кнопку «ответить», чтобы высрать какую-то рандомную чушь не в тему?

Lrrr ()
Ответ на: комментарий от Lrrr

А мой очередной вопрос в теме, видать так и остался незамеченным…
Может все же ответит на него, кто касался данного действия?
Фразу-пароль можно поменять или нет?

parnyagan ()
Ответ на: комментарий от parnyagan

Сам спросил - сам ответил.
Делается это командой gpg --passwd --change-passphrase userID .
Может кому пригодится на будущее…

parnyagan ()
Ответ на: комментарий от mord0d

В качестве бэкапа — подойдёт. Для безопасного использования — нет.

Как, по вашему мнению, безопасно хранить ключи?

parnyagan ()
Ответ на: комментарий от parnyagan

Бэкап на шифрованном разделе.

GnuPG и OpenSSH при инициализации создают файлы/директории с оптимальными правами.

mord0d ★★★ ()
Ответ на: комментарий от parnyagan

А это уже как тебе удобно.

У меня бэкапы хранятся на диске, делаются автоматически по расписанию. С флэшкой такой фокус не прокатит.

mord0d ★★★ ()
Ответ на: комментарий от mord0d

А это уже как тебе удобно.

У меня бэкапы хранятся на диске, делаются автоматически по расписанию. С флэшкой такой фокус не прокатит.

В этой теме мы разбирали GPG+SSH. А данный вопрос уже достоин новой темы.

Кому интересно развитие данного направления - переезжаем ===> Зашифрованный раздел на HDD/USB для хранения данных.

parnyagan ()
Ограничение на отправку комментариев: только для зарегистрированных пользователей