Comments 46
Чем ключ безопаснее 20-символьного случайного пароля?
Тем, что сервер его не знает даже временно. Даже если пароль в норме не хранится на сервере, в момент проверки сервер его получает в открытом виде. Если у сервера нечестный админ или если сервер заражен вирусом, он может в этот момент подсмотреть и сохранить пароль. В случае ключа это невозможно, поскольку сервер вообще никогда не видит приватный ключ клиента, он знает только публичный ключ и с помощью серии вопросов убеждается, что у клиента приватный ключ действительно есть. Даже если нечестный админ или вирус все это подсмотрит и запишет, это никак не поможет узнать ключ клиента.
А ещё приватный ключ тоже можно зашифровать (буквально) паролём, и тогда для входа надо будет вводить пароль. Но этот пароль будет использоваться только локально и только чтоб расшифровать локальный закрытый ключ. Если у вас этот ключ украдут, то воспользоваться всё равно не смогут.
На сервере ещё можно настроить требование логиниться по комбинации "пароль от учетки + ключ".
Как это сделать? Чтобы И пароль с логином И ключ был нужен? Но чтобы без чего-то одного нельзя было войти.
PAM. Там можно много интересного накрутить. Но однако практичнее комбинация, когда либо по ключу, либо по двойному паролю (пароль от учётки + одноразовый код). По 'PAM 2fa' можно нагуглить решения.
Как это сделать?
В sshd_config есть директива AuthenticationMethods. После нее следует указать перечень методов аутентификации, которые юзер должен пройти одновременно чтобы залогиниться. Например
AuthenticationMethods publickey,keyboard-interactive
Не смотря на всю математику и тьму алгоритмов, это классический пример opensourceware - когда вам открыто и бесплатно предлагают вроде неплохое решение для энтузиастов, а нормальное потом лишь за ненормальные деньги.
Ключи в SSH не имеют срока жизни и их практически нереально отозвать в случае компрометации, ухода сотрудника или же банальной ротации. Такое решение ущербно от природы и в этом смысле они ни чуть не лучше паролей. Хорошо если вы гуру secrets management, точно знаете исчерпывающий список серверов, где их использовали и имеете возможность оперативно отовсюду удалить. А если нет?
И тут вы обнаруживаете, что допустим ssh.com не просто так использует коммерческий домен. Здесь они прямым текстом топят за прямо противоположный passwordless/keyless approach с короткоживущими токенами и предлагают не маяться дурью, а закупиться PrivX. Все популярные cloud предлагают какие-то подобные аналоги, но по сути это тоже решение за которое надо платить.
Ключи в SSH не имеют срока жизни и их практически нереально отозвать в случае компрометации, ухода сотрудника или же банальной ротации.
Эти же проблемы есть и у доступа по паролям. Везде, куда юзер может лезть по ssh с паролем, надо будет что-то делать в случае увольнения юзера и компрометации его пароля.
Ключи, кстати, могут быть ограничены по времени жизни - это правило пишется в ~/.ssh/authorized_keys прямо вместе с самим ключем.
Как будто openssh не умеет использовать PAM.
Ключи в SSH не имеют срока жизни и их практически нереально отозвать в случае компрометации, ухода сотрудника или же банальной ротации
почему нереально? Есть всякие KRL и так далее. Добавляем строку RevokedKeys в sshd_config, и можно увольнять.
А что мешает пароли от учёток юзеров раздавать через LDAP? SSH умеет в LDAP. А что мешает публичные ключи юзеров раздавать через LDAP на тачки? Уволился сотрудник — централизованно удаляем записи о пользователе, и его пароле и ключе, и всё. Кроме LDAP есть ещё варианты использования связки SSH + Keycloack + Vault. Принудительная ротация ключей и смена паролей в таком случае тоже вполне себе реализуемый челлендж. Некоторые компании для подобных действий по блокированию/удалению учёток даже удобный WebUI себе пилят. В принципе, реализовать такое на каком-то Django, или даже flask + flask-bootstrap — вполне себе посильная задача даже для админа-одиночки. В случае с Keycloack даже пилить свой отдельный WebUI не нужно. И вот у вас уже возможность оперативного удаления ключей/хэшей паролей со всех ваших тачек, и даже с WebUI, так чтобы безопасник мог их выпилить даже зайдя куда надо со своего смартфона...
SSH же умеет вход по ключу и сертификату. Срок жизни этого сертификата можно сильно ограничить. Да хоть на каждое соединение новый создавать.
Эта штука прекрасно работает, например, с HashiCorp Vault:
https://developer.hashicorp.com/vault/docs/secrets/ssh/signed-ssh-certificates
Важно! Ни в коем случае нельзя никому сообщать свой закрытый ключ (по умолчанию
~/.ssh/id_rsaбез расширения.pub). Это всё равно, что рассказать свой пароль, только пароль можно сменить самому, а чтобы сменить ключ, надо дёргать администратора.
Вообще-то нифига подобного. Достаточно на машине, откуда запускается клиент ssh, сделать ssh-keygen и вместо старой пары ключей сгенерить новый. Залогинившись по старому, прописать в .ssh/authorized_keys новый. Ситуация ровно точно такая же как с утёкшим паролём: можно или просить админа прибить вообще любые пароль/ключи юзернейма на целевой машине, или же понадеявшись на авось, зайти старым паролём/ключём и сменить на новый.
расшифровывает строку открытым ключом
Это тоже не до конца верное утверждение. В общем случае именно что проверяется подпись, т.е. при помощи открытого ключа проверяется, что подпись была сформирована тем, кто имеет закрытый. Далеко не все алгоримты цифровой подписи позволяют ещё и что-то шифровать/расшифровывать ключами.
Кроме того, проверка подписей (как сервера так и клиента) позволяет защититься от атаки типа man-in-the-middle, когда злоумышленник вклинивается в обмен между клиентом и сервером, клиент думает, что он выработал общий симметричный ключ с сервером, но на самом деле с злоумышленником, то же верно и для сервера, а злоумышленник расшифровывает и зашифровывает данные между ними. Подписывается информация, известная и клиенту и серверу, но лоумышленник не имеет закрытых ключей чтобы сформировать корректную подпись, соответственно и атака man-in-the-middle будет разоблачена.
Спасибо за замечания, отредактировал статью. Сказывается невеликий опыт в системном администрировании и криптографии)
Достаточно на машине, откуда запускается клиент ssh, сделать
ssh-keygenи вместо старой пары ключей сгенерить новый. Залогинившись по старому
старый ключ надо бекапнуть, чтоб случайно не перезаписать новым.
Если старый ключ скомпроментирован, его нет смысла сохранять.
Как вы зайдёте на сервер чтобы записать туда новый ключ если потеряете старый?
Резонно. Кэп говорит что единственный способ связи нарушать нехорошо, да.
Что и доказывает, в линуксах не всё так хорошо с безопасностью как кажется. Просто перестать использовать ключ (и ничего не сломать) недостаточно. Нужно еще и вычистить из authorized_keys на всех хостах. Да, если приватный ключ утерян - нет гарантии, что злоумышленник с ним не залогинился и не добавил свой собственный ключ.
Тема Message Authentication Code (MAC) не раскрыта. Если бы этого не было то MitM мог бы заменить передаваемые данные на всякий мусор. То есть шифрование само по себе защищает только от прослушки и от замены передаваемых данных на осмысленные данные злоумышленника. Шифрование не защищает от замены передаваемых данных на мусор, это делает MAC.
Цель была описать части SSH, с которыми приходится иметь дело при использовании протокола будучи рядовым разработчиком. MAC вещь важная, но при использовании протокола с ним обычно иметь дело не приходится, он находится совсем под капотом в реализациях протокола (по крайней мере я ни разу не слышал/не видел в статьях про SSH упоминание MAC, полагаю часть про него вообще не знает, часть не считает нужным обсуждать, так как реализации сами разбираются с ним). Так что я позволил себе посчитать MAC одной из тех самых "продвинутых возможностей", пусть он и заложен практически в основу протокола. Возможно напишу ещё что-то про SSH и раскрою тему MAC, но здесь считаю лишним его разбор.
ключа имитовставки (integrity key),
А откуда лексика взята? integrity key вполне себе по-русски "ключ целостности", насколько мне известно.
https://ru.wikipedia.org/wiki/Имитовставка
А вообще, мне название "ключ целостности" кажется немного размытым. Всё-таки "имитовставка" подразумевает, что это дополнительная "вставка" в сообщение, а "ключ имитовставки" соответственно нужен чтобы эту "вставку" сгенерировать и проверить. А "ключ целостности" по-моему никак не описывает, что он из себя представляет и как именно используется. Но кому как, я знаком с MAC только по английским ресурсам, не возьмусь утверждать, какая терминология закрепилась в русском.
В плане размытый? У вас используется лексика из какого-то старого отменённого ГОСТа судя по статье из вики, которая как минимум является неинтуитивной, и как максимум вообще семантически неверной. Сравните хотя бы вот с этим.
Во-первых, то, что её ввели в старом отменённом ГОСТе, не значит, что она неверная. Возьмите, например, ГОСТ Р 34.13-2015. Издан в 2016 году, сейчас действует, и использует эту лексику.
Во-вторых статья, которую вы привели говорит о целостности в совершенно другом контексте, собственно в этом и размытость. Имитовставка, она же MAC — вполне конкретное понятие, набор байт, благодаря которому можно убедиться в целостности сообщения. Целостность — очень общее понятие, которое применимо к самым разным контекстам. Если хотите, говорите "ключ целостности". Я же считаю, что "имитовставка", как более узкий термин, здесь уместна, а раз алгоритм имитовставки, то и ключ для него предпочитаю называть ключом имитовставки.
Прочитал про "имитовставку". Написано так, что не зная заранее -- даже не поймёшь о чём речь. На самом деле всё гораздо проще. Это может быть обычный криптохеш типа SHA256 от конкретного пакета SSH (не путать с пакетами IP, TCP и т.д.), по алгоритму HMAC замешанный с секретным ключом. Или же равносильные по взломостойкости (при условии применения секретного ключа) алгоритмы типа UMAC или GCM (последний ещё и способ применения шифра устанавливает). Ещё пример -- бандл шифра и MACа типа ChaCha20-Poly1305. Но суть всегда одна -- хеш, который не зная секретного ключа, невозможно подделать.
Ну, например "OpenSSL 3. Ключ к тайнам криптографии". Свежая книжка (2023) от ДМК.
Там именно "имитовставка". Возможно, переводчик посмотрел в википедии, но термин вполне на слуху. Просто обычно с криптографией говорят в терминах оригинальных нерусскоязычных аббревиатур. А там MAC - требует контекста. (mac-адрес устройства ethernet?). Имитовставка сразу понятна.
не упомянули, что можно выбрать тип ключа через
ssh-keygen [-t dsa | ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa]
Рекомендуется использовать ed25519, а не rsa.
при смене ключей на сервере, на клиенте можно воспользоваться
ssh-keygen -R hostname
удалит старый отпечаток и добавит новый.
Добрые люди, скажите. Ежели я настраиваю аутентификацию по ключу, то мне приватный ключик надоть беречь как зеницу ока? И ежели я его потеряю, то доступ к серверу мне будет закрыт, да?
Тапками прошу не кидать, ибо я слабовать в таких технологиях. Не айтишнег йа.
На просторах нашел принудительное указание протоколов. Для исключения заведомо уязвимых. Конечно и в этих со временем нароют.
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com 
Хотел увидеть, но не увидел про клиента на "нашем всём" - на винде (прощу прощения у поклонников Linux).
Так что жду продолжения!
А там и на Шекспира ssh на MacOS можно замахнуться! 😃
Не особо пользуюсь виндой, но там точно есть putty. Ну и на свежих версиях с wsl, внезапно, openssh.
А с макос что? Там есть обычный ssh (думаю, тот же openssh)
Вдохновляющее предложение, но не вижу большой ценности в том, чтобы разбирать реализации) Если у меня получилось описать протокол в целом так, чтобы был ясен смысл основных его особенностей, не должно быть трудно разобраться, как работают конкретные реализации. Практических гайдов, как настроить тот же putty вроде как уйма, а про OpenSSH тут заикался чисто ради примера, иначе бы вышло абстрактное повествование в вакууме. Так что вряд ли дождётесь, всё-таки я скорее теоретик, чем практик)
SSH с высоты птичьего полёта, или разгребаем кучи ключей