На месте, и уж точно никуда не копирую и не бэкаплю во избежание. Не имею ничего, доступ к чему держался бы на одной лишь неутере приватного ключа SSH, и тебе советую.
Храню в ~/.ssh, пределов машины ключи не покидают. На каждом компьютере свои ключи. Для первого входа есть пароли. На мой взгляд хранить ssh-ключи, как отдельный артефакт - идея не очень правильная.
51 статья Конституции (отказ от дачи показаний, имеешь полное право и за это ничего не будет), если угрожают, бьют - просто жалуешься в собственную службу безопасности (как показала практика в условном Задрищенске не поможет), прокуратуру, генеральную прокуратуру… Иногда работает, но чего точно не стоит делать, так это давать признательные показания. С точки зрения закона даже логи являются косвенными доказательствами (так как это обычные файлы, которые кто угодно и когда угодно может подменить), другое дело, что ментам на соблюдение закона все равно (однако никто не отменял планы прокуратуры по посадкам следаков и оперов).
В наше то время еще разбрасыватьcя публичными ключами по серверам то?
На носителе держится ca-key, везде ходится по сертификатам. Приватные ключи генери хоть каждые 10 минут для одноразового использования. Без подписи - хоть в газете публикуй - толку от них - 0.
В идеале — альтернативный способом доступа (serial port, физический доступ, …) . Если для чего-то у тебя так делать не вариант, то альтернативным способом авторизации тоже сойдёт, но остаётся тогда вопрос, как ты предохраняешься от локаута при мисконфигурации.
Все ключи в одном каталоге. Все IdentityFile для 128 серверов прописаны в него. Этот каталог зашифрован gpg. Если нужно использовать доступ куда-либо - расшифровывается один каталог и используется обычный alias для ssh. Если не нужно - от так и остался зашифрованным. Таким образом, в голове только 1 пароль - от gpg-ключа. Дешево и сердито. Но не настаиваю, спросили - ответил.
Каким образом етот вариант может предотвратить следующее: кто-то другой приконнектившись к твоему компу под твоим именем коннектится дальше по ssh?
У моего компа нет «входных» точек для коннекта. :)
А если более серъезнее, то short lived certificate уже протух, и он может хоть на стене у себя распечатась мой серктеный ключик - толку от него никакого, так-как публичной части нет нигде в интернете… :)
Да понятно, что -A работает везде. Просто это немного наивно, человек пишет разумную мысль, что ключи должны быть не в Директории.ssh, а в более серьезном месте.
Не понимаю, в чем разумность этой мысли. Я согласен, что на юбикее хранить их лучше, но до такой техники пока руки не дошли. А всякие извраты с gpg это от избытка свободного времени, как по-мне.
Они какое то дерьмо замутили в режиме secure key (sk). Там приватный ключ делится на две половины, одна типа в системе как обычный приватный ключ а вторая в ключе. Для работы нужны обе половинки. То бишь надо таскать флешку с одной половиной и ключ с другой. А опция resident позволяет обе половины хранить в ключе.
Так тут вся тема для тех, у кого руки дошли до рутокена или yubikey. ;)
Просто это стоит денег (один юбикей стоит 6-7 тысяч руп) и организационных мер, иначе останешься без токена перед компом и как работу работать?
Я в качестве промежуточной меры использовал encfs. Вполне себе бюджетное решение.
А всякие извраты с gpg это от избытка свободного времени, как по-мне
не извраты, а штатный режим работы. Один раз прочитать ман или какой-нибудь туториал в интернете, зато потом ты сможешь и по ssh ходить, и в passwordstore пароли шифровать, и делать всякое прочее вроде разблокировки рута, не ставя дополнительного софта, не теряя в удобстве и храня ключ в юбикее.
Они не дают никакой безопасности перед обычным ключом в ~/.ssh. Если твоя машина скомпрометирована и троян шуршит по твоим файлам, он и твои gpg-ключи вытащит и твою клавиатуру отсниффит, вытащив пароли к ключам. Т.е. ты просто себе усложняешь жизнь, не усложняя её взломщику. Юбикей даёт преимущество - во-первых с него не вытащишь ключ никак, во-вторых, насколько я знаю, операции с ключом требуют физического касания, т.е. без твоего ведома его использовать нельзя. А всё, что там с файлами происходит - это баловство.
Потому, что при форварде агента у тебя на промежуточном хосте появляется открытый сокет к агенту, который атакующий может переиспользовать, если скомпроментирует этот хост.
Более правильный способ - использовать директиву ProxyJump, которая работает так: клиент подключается к промежуточному хосту, запрашивает форвардинг порта к целевому хосту, не открывая при этом шела, после чего подключается к целевому хосту через этот форвард. Таким образом, с точки зрения ssh у тебя два соденинения - к промежуточному хосту и к целевому хосту, а это не требует прокидивать ключ на промежуточный хост (да и, во многих случаях, на целевой).
Поскольку на промежуточном хосте не нужен шел, то у львиной доли пользователей, ходящих через него, можно в качестве шела использовать /sbin/nologin. Хотя, я написал ему мини-замену с немнгого улучшенным логированием: https://gitlab.com/kevinreed/forsh.