После четырёх месяцев разработки представлен релиз OpenSSH 8.4, открытой реализации клиента и сервера для работы по протоколам SSH 2.0 и SFTP...Подробнее: https://www.opennet.me/opennews/art.shtml?num=53793
долгие лета ssh-у!
> долгие лета ssh-у!Хм.
И Вам не хворать, а то весь красный. :)
Не представляю жизни без SSH. Ждём ебилдов.
>...Ждём ебилдов.Не жди:
net-misc/openssh
Доступные версии: 8.1_p1-r4 (~)8.2_p1-r7 (~)8.3_p1-r5 (~)8.4_p1
>FIDOТак и запишем: проект OpenSSH деятельно содействует ZOG в лице FIDO Alliance в насаживании общества на зонды. Будет учтено при вынесении приговора.
где вы из под своей шапочки из фольги разглядели в этих алгоритмах для аутентификации зонды? не шиза ли это, товарищ?https://fidoalliance.org/specifications/
https://github.com/fido-alliance
https://research.kudelskisecurity.com/2020/02/12/fido2-deep-.../Читаем до просветления.
На самом деле хотелось бы ваших коментариев.Лично я по ходу чтения понял что ничего не помешает сделать софтварный FIDO2 токен, что сведётся к банальному манагеру паролей.
И что это за извиняюсь "материал" и коим боком ссш с ним связан ? Или это надо через сишную дырень смотреть ?
вероятно, речь о третьих игроках, которые не вредят торговлей безопасностью и даже кровно заинтересованы в чистоте mfa репутации.
Что вы такое несёте? Это-же товарищ майор. При нём таких слов употреблять нельзя. И вообще зачем вы ему ссылки с таким кол-вом букв отправили? Это вообще издевательство какое-то.
Можно ли как-то отключить проверку по .ssh/known_hosts, если у удаленного сервера что-то там изменилось в связи с переустановкой или еще чем-то там? Для локалхоста совершенно бесполезнейшая фича, надоело удалять строку из .ssh/known_hosts каждый раз, когда коннекчусь к свежепереустановленной локальной виртуалочке.
прошиваю кучу девайсов, сделал себе скрипт, который удаляет хост из known_hosts и заливает сертификат, кроме прочего, чтобы пароль руками не вводить. дёргаю как fix_ssh.sh 123 (сеть 192.168.2.X)
Пропишите в ~/.ssh/config эти параметры. Можно сделать поHost 192.168.*
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=noПодсеть подставить по вкусу
sudo apt purge openssh-client -y && cd ~/ $$ rm -rf .ssh проще не ?
1. Попробуй сделать это не на deb-дистрибутиве (и не на альте)
2. Ключи заново рассылать не замучаешься?
1. На нынешнем альте сперва скажут "нет команды apt" (apt-* есть), а apt-get скажет "ошибочная операция" (remove есть, но у rpm нет промежуточных состояний вроде "пакет немного установлен").
2. Совет вообще страшно отдаёт убунтой -- сносить _клиента_, чтобы снести вместо ~/.ssh/known_hosts (а точнее, от одной до шести строк в нём) сразу весь ~/.ssh с ключами и config... рука тянется к ссылке "умодерировать", хотя вдруг кто-то на этом научится не делать бездумно "подсказанное в интернете".
Веришь, нет — замучился каждый раз объяснять студентам: видишь незнакомую команду или конфиг — смотри прежде всего man, или ещё какую родную документацию. Нет, привыкли ходить в гугл на каждый чих... Наглядно показываю каждый раз, что это медленнее и менее надёжно, «угу», и через пять минут снова-здорово.В общем, было у нас поколение «Пепси», а нынче — поколение «Гугл».
Точно, надо вообще для "удобства" всего одну опцию:
GoToHellWithSecurity = yesP.S.
Для копи/пастов & next-next-ов :
выше рекомендованные опции - означают игнорирование возможной MITM атаки
МИТМ-мужик между мной и локалхостной виртуалочкой? ты наверное и туалет в квартире на навесной замок запираешь?
С рождением ребёнка - да. =(
> МИТМ-мужик между мной и локалхостной виртуалочкой?"если у удаленного сервера что-то там изменилось..." != localhost
>ты наверное и туалет в квартире на навесной замок запираешь?Тебя правда интересуют мои туалеты???
> "если у удаленного сервера что-то там изменилось..." != localhostПочему? У тебя есть два чувака: SSH-сервер и SSH-клиент. localhost это SSH-клиент, виртуалка на локалхосте -- удаленный SSH-сервер.
может ман почитаеш.. ну же!
> отключить проверку по .ssh/known_hostsОтвет: да.
Высшее образование - это умение находить нужные знания в источниках.
В каких ? В интернетах ? Лол, нафиг такое образование тогда.
В документации. Прилагаемой к ssh, sshd, ssh_config, sshd_config и так далее. До-ку-мен-та-ции. Не первой ссылке в Гугле и не второй в Яндексе. В документации! Понятно?
Настрой SSH сертификаты, не придется возиться с known_hosts.
Если аутентификация хоста не важна то можно получить хеш ключа хоста и добавить его себе в .ssh/known_hosts автоматически, скриптом.
ssh root@my_heart
UpdateHostKeys
я много лет ждал
Не понял про отключение ssh-rsa. Это какой-то короткий rsa, вроде rsa-140? Или rsa-2048 тоже отключат, соответственно, команду "ssh-keygen -t rsa -b 2048" считать устаревшей?
Вообще уже много лет рекомендуется использовать ed25519, а не rsa. Так что да, указанная тобой команда устаревшая
Правильная команда ssh-keygen -o -a 100 -t ed25519
Yes, sir, господин полковник NSA, мы задачу чётко поняли.
Да это уже всё, за какие-то 5 лет те бэкдоры стали неактуальны, теперь будет на роли DES https://en.wikipedia.org/wiki/Post-Quantum_Cryptography_Stan...
Да, вот только эта рекомендация из серии: ECDSA работает быстрее и данных меньше гонять.
Других никаких аргументов против RSA нет совсем.
А вот против ECDSA есть:- пресловутые тайминг атаки, которые впрочем крайне легко нивелировать добавив простой таймер, типа посчитаем сразу но ответ всегда будет отдавать через 5-30 секунд от момента прихода запроса.
- кубитов для взлома RSA нужно сильно больше, при этом каждый может сгенерировать себе RSA с 32768 битами прямо щас, а вот в ECDSA всё жёстко зашито и там максимум вроде 521 бит для одного из наборов, остальные ещё меньше.
В ed25519 вообще 256 или даже меньше бит, так что это совсем плохое решение, которое дурно пахнет. Собственно заявленные автором "state of art" уже намекают на применение :)
Лично я предпочитаю оставлять только RSA, отключив все ECDSA и ED25519, а для RSA иметь длину ключа 16384 - оно долго считается и требует много памяти, но:
- крайне надёжно
- всякие брутфорс боты просто дохнут на хэндшейке ибо привыкли к 2048:
Sep 28 15:57:29 firewall sshd[8272]: error: kex_exchange_identification: Connection closed by remote host
Sep 28 16:05:39 firewall sshd[77334]: error: kex_exchange_identification: read: Connection reset by peerвот так выглядит более половины попыток брутфорса пароля по ssh у меня :)
А как для ssh сгенерить rsa >8192? И главный вопрос, это все серверы подерживают?
ssh-keygen -t rsa -b 16384 -f /usr/local/etc/ssh/ssh_host_rsa_key -N ''
OpenSSH точно тянет, остальным не интересовался.
> при этом каждый может сгенерировать себе RSA с 32768 битами прямо щасХммм, мне в ответ ssh-keygen говорит - key bits exceeds maximum 16384
Ну и да с такой длиной ключа к клиенту секунд 20-40 подключатся хехе.
Кстати да, возможно.Я помню год назад у меня гит или что то ещё вываливало варнинги из за ключа 16384 бит, но как то незаметно пофиксилось с каким то апдейтами :)
В любом случае, 16384 - это секурность эквивалента которой нет в отрасли, кажется 2048 или 4096 от RSA эвивалентно максимальному ECDSA, по таблице эквивалентности от NIST.
> от NISTА-аа.
Ну и о печальном, теперь деватся некуда, rsa тов майора неустраивает, его просто вырубят и все.
ssh-rsa это просто название конкретного _одного из кучи_ алгоритмов в которых используется rsa, вы новость дальше дочитайте:> Среди рекомендуемых для миграции алгоритмов упомянуты rsa-sha2-256/512 на базе RFC8332 RSA SHA-2 (поддерживается с OpenSSH 7.2 и используется по умолчанию)
Ух, пардон, упустил.
Вообще то нет.На самом деле NIST двигал тему что теперь есть ECDSA и RSA как бы уже не нужен, ну он же типа дольше считает заметно при эквивалентном уровне секурности что и ECDSA.
Но год или более назад они заткнулись, и перестали пропихивать у себя везде ECDSA в замен RSA.
Есть мнение что потому что нашлась слабость в ECDSA или кто то в подвале сделал комп с нужными кубитами, но типа официально решили что лучше дождатся постквантовой крипты, чтобы два раза не вставать и кипишь не поднимать.Если кто не знает ECDSA - это с 1998 года тема, те 20+ лет, тогда его банкиры оплатили, для себя видимо.
То что там потом Бернштейн навертел в ED25519 - тема интересная, но по сути единственное чем оно типа лучше - отсутствие тайминг атак. Как минимум один публичный минус в том, что там только один жёстко заданный набор параметров и оно типа 256 бит элиптики, что эквивалетно 128 бит симметричной крипте. И там какая то оговорка была, что он ещё два бита под целость использует, так что выходит 126. Но про это мало где пишут.Я не знаю есть ли какие либо минусы у cahacha20 или poly1309, тоже творений того же гения, но ed25519 лично у меня вызывает сомнения, как минимум своим маркетингом.
Отсюда выходит что и поделия где оно прибито гвоздями тоже сомнительные, а это тот же wreguard, который так внезаптно без вопросов протащили и в ядро линуха и в некоторые BSD системы.
Те оно опять слишком хорошо чтобы быть правдой.
Какие то чуваки всего за год втащили своё поделие сразу в 2-3 операционки, притом что другие не могут втащить туда куда более простые подсистемы и даже фиксы.И потом, как можно делать протокол где крипта прибита гвоздями!?
На это уже столько раз наступали, и теперь md4, md5, sha1 с нами на очень долго именно поэтому.
И как можно было пустить такой протокол в ядро, когда это очевидный косяк?
Опять же, можно посмотреть кто это делал.
Поделия Бернштейна популяризировал гугл, и он же способствовал их встаскиванию в TLS.
При этом публичные пояснения гугла о том, что им и пользователям это экономит электричество с натяжкой но принять можно. Возможные риски гуглу тут не интересны (настолько что они даже свою постквантовую крипту вместо ed22519 тестят на хомяках), они вообще ничего не теряют.
И вероятно они по тихому выкинут chacha20 через какое то время в пользу AES - потому что оно уже почти везде аппаратно есть, а через 5 лет и подавно везде будет. Если только chacha аппаратные блоки не появятся в процах.
Если кратко: нет, не выкинут.
В Curve25519 тоже 256 битов, её отключаешь?
Какие есть тулзы/wrapper под Linux для управления FIDO/SSH группами ключей?
Seahorse
Интересно в ubuntu 20.04 LTS появится эта версия 8.4 или все так же и будет 8.2 ?
Где там iPony со всем устаревшим?
Запарили со своими обновлениями, приходится огребать client_loop: send disconnect: Broken pipe в зависимости от расположения звезд на небе.