После шести месяцев разработки представлен (http://lists.mindrot.org/pipermail/openssh-unix-dev/2017-Oct...) релиз OpenSSH 7.6 (http://www.openssh.com/), открытой реализации клиента и сервера для работы по протоколам SSH 2.0 и SFTP. Выпуск примечателен удалением из кодовой базы всех компонентов, связанных в реализацией протокола SSH1.Протокол SSHv1 был признан устаревшим около 10 лет назад и серверная часть SSH1 была удалена достаточно давно, но возможность сборки клиента для SSH1 оставалась, что позволяло использовать актуальные выпуски OpenSSH для соединения с устаревшими системами и некоторым оборудованием (например, устаревшие модели Cisco и HUAWEI). Отныне код избавлен и от клиентских компонентов SSH1. Кроме недостаточного уровня защиты, обеспечение сборки с SSHv1 накладывало ограничения на кодовую базу. Например, работа OpenSSH без привязки к библиотеке OpenSSL возможна только при использовании протокола SSHv2 и отключение SSHv1 позволяет организовать поставку в дистрибутивах конфигураций OpenSSH, собранных без привязки к OpenSSL и самодостаточных в плане методов шифрования.
Полное прекращение поддержки SSH1 также позволило удалить реализации шифров arcfour, blowfish и CAST, а также RIPE-MD160 HMAC, которые были по умолчанию отключены в настройках. Кроме того, отныне запрещено использование RSA-ключей размером менее 1024 бит и отключена по умолчанию поддержка шифров CBC на стороне SSH-клиента (в сервере CBC был отключен несколько лет назад).Другие изменения:
- Устранена проблема безопасности: sftp-server позволял создавать файлы нулевой длины, несмотря на включение в настройках режима только для чтения;- В клиент ssh добавлена директива RemoteCommand, через которую можно на уровне файла конфигурации задать команду для выполнения на удалённой стороне сразу после входа, по аналогии с указанием команды в командной строке;
- В sshd добавлена опция ExposeAuthInfo, позволяющая организовать запись в файл лога с расширенными сведениями об используемых методах аутентификации;- В клиент ssh добавлена поддержка динамического реверсивного проброса (reverse dynamic forwarding), при включении которого локальный ssh начинает работать как прокси SOCKS4/5, перенаправляющий через локальную систему соединения, запрошенные SOCKS-клиентом на удалённой стороне. Режим включается при помощи опции "-R" (RemoteForward) и реализован целиком на стороне клиента (может работать со старыми версиями sshd).
- В sshd разрешено указание директивы LogLevel в блоках Match файла конфигурации sshd_config;
- В ssh-keygen разрешено добавление произвольной строки или флага в создаваемый сертификат;
- В ssh-keygen обеспечена возможность использования ключа, хранимого в ssh-agent, в качестве CA при заверении сертификатов;- В ssh и sshd разрешено указание флага IPQoS=none для выставления в ToS/DSCP значения, предлагаемого по умолчанию операционной системой;
- В ssh-add добавлен флаг "-q" для запуска ssh-add без вывода информации на экран;- В ssh добавлены два новых режима работы директивы StrictHostKeyChecking:
- "accept-new" для автоматического принятия до сих пор не встречавшихся ключей, но блокирования сеансов для изменившихся или некорректных хостовых ключей (более безопасный вариант режима StrictHostKeyChecking=no);
- "off" - синоним ранее доступной настройки "StrictHostKeyChecking=no", при которой автоматически принимались до сих пор не встречавшихся ключи и разрешались соединения с известными некорректными хостовыми ключами;
- В ssh добавлена директива SyslogFacility, аналогичная ранее доступной директиве в sshd;- При запуске sshd в Solaris обеспечен сброс дополнительных привилегий в sandbox-режиме: PRIV_DAX_ACCESS и PRIV_SYS_IB_INFO;
- В sshd реализована передача в PAM списка выполненных методов аутентификации через переменную окружения SSH_AUTH_INFO_0;
- Добавлены сборочные флаги "--with-cflags-after" и "--with-ldflags-after" для установки CFLAGS/LDFLAGS после заверения выполнения скрипта configure (полезно для принудительного подключения отладочных средств проверки кода и fuzzing-тестирования;- Добавлена поверка на основе clang libFuzzer для кода разбора открытых ключей и верификации сигнатур.
URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/2017-Oct...
Новость: http://www.opennet.dev/opennews/art.shtml?num=47324
вот accept-new это реально полезно
Воистину так!
Мы тоже одобряем.
> В клиент ssh добавлена директива RemoteCommand, через которую можно на уровне файла конфигурации задать команду для выполнения на удалённой стороне сразу после входаВангую волну червей использующих эту фишку
>Вангую волну червей использующих эту фишкуДа с чего бы?
Во-первых, подобный функционал давно используется.
Во-вторых, коль по ssh уже зашли на хост, данная возможность ничего не прибавит и не убавит.
> Да с чего бы?
> Во-вторых, коль по ssh уже зашли на хост, данная возможность ничего не прибавит и не убавит.Ну, наверное, я что-то не так понимаю. Я представил себе обычного непривилегированного пользователя, машина которого была как-либо заражена в первый раз. Например, веб-мастер. Его ssh конфиг меняется, и добавляется команда которая при логине на хост (например на stage, production, а еще лучше CI сервер проектов над которыми он работает) добавляет аналогичную команду которая меняет ssh конфиг авторизованного пользователя. Червь может и не знать пароль от серверов, пользователь введет его самостоятельно при подключении. Он также может залогиниться куда-нибудь как root.
Допустим он залогинился на CI чтобы поменять настройки. на CI ssh конфиг поменялся. В следующий раз когда CI будет логиниться на stage или production, процесс повторится. Возможно такое?
Возможно конечно, извращаться можно по разному, а можно не ждать у моря погоды, а сразу пройтись по всем хостам, к которым юзер когда-либо подключался, и сделать там своё темное дело. Так и быстрее и меньше следов.
> Возможно конечно, извращаться можно по разному, а можно не ждать у моря
> погоды, а сразу пройтись по всем хостам, к которым юзер когда-либо
> подключался, и сделать там своё темное дело. Так и быстрее и
> меньше следов.Если юзер по паролю логинится или ключ зашифрован и агент не запущен, тогда в этом RemoteCommand есть скрытый смысл, чувак прав.
Червь меняет вызов ssh через алиас на свой враппер, который просто перехватит пароль к серверу и ключу - вуаля. Если машина скомпрометирована, то лучший путь - переустановка с нуля, т.к. наворотить можно при желании так, что пол жизни разбираться будешь.
Звучит правдоподобно.
Но судя по описанию, в таком случае интерактивной сессии не случится. Смотреть надо.
> Вангую волну червей использующих эту фишкуавторы червей - грамотные ребята, и давно ее заимплементили самостоятельно. Но да, теперь им можно расслабиться и поддерживать одним куском кода меньше ;-)
Есть механизм обновления в ~/.ssh/authorized_keys старого публичного ключа на новый? Например я сгенерил себе новый ключ, загрузил оба ключа в агента для авторизации на "старых" и "новых" хостах и хочу чтобы по мере обхода на "старых" хостах (со старым ключом) в момент входа старый ключ заменялся на новый.
агент _ничего_ не знает о твоем публичном ключе.
А хосты ничего не знают о том, что он "cтарый".
учи матчасть, еще один sed-неосилятор.
authorized_keys на сервере описывает ключи, по которым сервер узнаёт вас (клиента). Если ключ не подойдет, то ты не сможешь даже залогиниться на сервере, не то что обновить authorized_keys. Но если старый ключ ещё есть, то можно написать скрипт, который будет с помощью старого ключа логиниться на сервер и подменять публичный ключ на новый в authorized_keys. man ssh.
Ну собственно вопрос товарища был - есть ли такое готовое, чтобы самому не писать. Как по мне - правильный вопрос, подобный менеджмент должен быть в коробке.
подобный "менеджмент" состоит из:
* импорта в ssh-agent обоих ключей (старый+новый)
* ssh-copy-id (или таки sed, как местный Прозревший под ником толи "пох" толи "нах" вещает в комментах которой уже новости)
* ssh host sed '/pattern to match(old_key)/d'
делаешь алиасом для ssh этот враппер и получаешь то, что изначально и хотел афтар
либо, к примеру, каким ансиблом/циклом на шелл это дело фигачишь
Да, sed, awk, ansible, ещё вагон костылей и скрипты поверх всего этого зоопарка. Разумеется для каждой ОС свой персональный набор костылей, о своими багами и приколами вплоть до "все ключи убиты, ни один не добавился, а авторизация по паролю запрещена" вместо функционала, который нужен из коробки, наравне с ssh-copy-id. Если ты не согласен, то не пользуйся ssh-copy-id, пользуйся scp и костылями по ручному добавлению в authorized_keys всякого (так жы веселей)
твои патчи ("функционала, который нужен из коробки, наравне с ssh-copy-id") отвергают или где?
ssh-copy-id с авторизацией по старому ключу, нет?
ssh-copy-id придётся каждый раз руками набирать, когда хостов много и они постоянно меняются, это лет за много лет безумно надоедает.
К тому же ещё устаревший ключ нужно дропнуть.
шелл, оказывается, тоже ниасилен, как и sed? Ну понятно, виндyзятник до такой степени - должен страдать.
Виндузятникам на эту фичу как правило плевать, потому что у них авторизация разруливается совсем иначе. Но ты продолжай рукоблудить-манкикодить на скриптах и конфигах, вдруг токсикоз пройдёт, полегчает
> хостов много
> они постоянно меняются
> много летЕсли за много лет в таком сценарии не освоен хоть поверхностно какой-нибудь ansible, то всё очень плохо.
жаль аркфору, быстрый был.
А что сейчас самое быстрое ??
aes128-gcm@openssh.com у меня выдает 500 МБ/сек (при копировании с localhost на localhost), это в полтора раза быстрее, чем arcfour в таком же тесте. Зачем он вам?
(проц, конечно, с поддержкой AES-NI, но это сейчас даже в атомах есть несколько лет как)
у меня есть файлопомойка на стареньком проце, тех времен когда о шифрации сильно не думали, точнее дурон 1ггц. он прекрасно работает, там валяетя синхронизируемая копия сд-карточки с телефона, куда периодически закидываю музон. требования к закрытости небольшие, а скорость никогда не помешает. я конечно утрирую, пофиг до скорости на таких задачках, но внутренний идеалист нажимает на жабу после такой картинки http://hsto.org/files/9b6/2b7/0a3/9b62b70a363d41d2a78f676b71... :)
> требования к закрытости небольшие, а скорость никогда не помешает. я конечно
> утрирую, пофиг до скорости на таких задачкахэ нет, это _твое_ время, а не машинное, которое _ты_ ждешь, пока оно докопирует.
> но внутренний идеалист нажимает на жабу после такой картинки
мой внутренний идеалист категорически против использования новых-модных версий openssh, сделанных неосиляторами для неосиляторов, чего и вашему желает.
вплоть до ручного пакетирования чего-нибудь 5.3 на основе редхатовской сборки с ручным бэкпортом патчей и всерьез подумывания, не откопать ли обратно исходники последних версий ssh1.вот ровно ни одна фича из появившихся за последние пять лет совершенно не нужна в реальном мире. В отличие от героически выпиленных в борьбе за светлое ничто.
> (проц, конечно, с поддержкой AES-NI, но это сейчас даже в атомах есть
> несколько лет как)у меня атом 2011го года - мне его в помойку нести, потому что ssh-вырежем-все-подряд-неписатели так решили?
(понятно, что я проживу без этого архинужного апргейда еще лет десять, а потом либо шах, либо ишак, либо сам ходжа, но что прикажете делать тем, кому достанется именно эта версия?)
Не хотите - не несите. А что, для остального (веб браузинг и тп) хватает, а вот скорости ssh прямо вот никак не хватает?Нашел под рукой древний Atom 2011 года (N2800). 1.86 Ghz, TDP 6.5W. Двухядерный даже! Никакого AES-NI и в помине нет, конечно. Выдает 27 МБ/с в aes256. Неплохо бы быстрее, но.. неужели это будет узким местом в каких-либо задачах под такой процессор?
> Не хотите - не несите. А что, для остального (веб браузинг и тп) хватаетс некоторыми разумными ограничениями - пока хватает. аппаратного ускорения видео, павшего жертвами таких же горе-разработчиков-всего-нового вместе с флэшем, конечно жаль (в винде нет проблемы).
> Неплохо бы быстрее, но.. неужели это будет узким местом в каких-либо задачах под такой
> процессор?ну вот хочешь ты скопировать побыстрому исошник на хранилку виртуалок, и бежать в другое место. Можно, конечно,заморочиться и настроить у себя ftpd. Потом залезть на хранилку и оттуда клиентом стащить. А можно просто запустить scp. Но с aes придется "немного" подождать. Примерно так вдвое больше, чем с blowfish, и втрое чем с none. none на хранилку возводить немного сложно. Исошника злым хакерам, разумеется, ни разу не жалко.
А время - оно твое идет.
Конкретно в данном случае - можно запустить копирование и убежать, на что там смотреть?А вообще - железа без аппаратной поддержки aes таки мало, ситуаций, когда критична скорость заливки по ssh на что-то внутреннее тоже мало, а их пересечение - совсем копейки. А пока эта версия распространение получит - так и вовсе поддерка аппаратного aes будет с каждом фантике от конфеты.
> Конкретно в данном случае - можно запустить копирование и убежать, на что там смотреть?прибежал, а оно, опа, отвалилось в процессе. Или места не хватило.
А может неплохо было прежде чем убегать ,еще и инсталл оттуда дернуть?В общем, много случаев, когда лучше дождаться конца операции, или работа вообще стоит, пока оно копируется.
И очень много - когда от ssh требуется только безопасность аутентификации, а не шифрованный канал (это не столько беда ssh, сколько забития всей индустрией на отличающиеся от ssh протоколы - ну как же, вот же, ж удобно жеж - все в одном флаконе).> А вообще - железа без аппаратной поддержки aes таки мало
ну, я теперь имею железный аргумент на следующей работе требовать с начальства ноут поновее - а то на моем "i3-2350M" тоже как-то aes'ом не пахнет, но вообще-то таких вполне еще приличных X230 не так чтобы "мало". Мало более новых, и не всем дают. Он, конечно, в любом случае не такой дохлый как домашний атом, и тормозить, наверное, будет приемлемо (не буду мерять, чтоб не расстраиваться).
> А пока эта версия распространение получит
ох... твои б слова да Богу в уши, но, боюсь, через пару месяцев уже где-нибудь да напорешься.
Да я ж не спорю, бывает. Но чтобы это было значимо в плане потерь времени - сомнительно. А свалить с зоопарка на одно решение - обычно выгодно с точки зрения бизнеса.Что до ноута - что-то у вас совсем печально с железом, могу только посочувствовать. Начиная с того, что вообще что-то на атомах или i3.
И где можно напороться в продакшне на что-то, что вышло пару месяцев назад? Я больше вижу обратное - стоны "блин, да обновитесь уже на версию, которой всего полтора года, а не четыре". Не на арче же у вас там системы.
В общем, я верю, что такая беда в каких-то случаях может возникнуть, но чтобы массово - ни шанса.
> Что до ноута - что-то у вас совсем печально с железом, могуда я как-то особых страданий не испытываю, мне на нем не жабу отлаживать (хотя, да, metro2033 не идет же ж, блин!) - а что, где-то инженерам что-то круче леновы пятилетней давности выдают по первому требованию?
> И где можно напороться в продакшне на что-то, что вышло пару месяцев
> назад? Я больше вижу обратное - стоны "блин, да обновитесь ужену вот обновился на текущую openbsd (только на днях и не совсем законным образом удалось тут похоронить зверушку - то есть оно реально используется в некоторых специфичных вещах)
- какой он там будет? Отож.> В общем, я верю, что такая беда в каких-то случаях может возникнуть,
> но чтобы массово - ни шанса.ну, может не завтра еще , но через несколько месяцев нарваться будет вполне реально, а через пару лет станет общим местом. И очень навряд ли у меня к этому времени не останется процессоров без AES-NI.
> ну вот хочешь ты скопировать побыстрому исошник на хранилку виртуалок, и бежать
> в другое место. Можно, конечно,заморочиться и настроить у себя ftpd.Так и запишем: 1. netcat не осилен; 2. виртуалки на какой-то дряни запускаются, которая даже upload в красивом динамичном web-интерфейсе не может.
ну, для нетката надо, как минимум, иметь лишний открытый порт в файрволле. А куда "красивый динамичный" засунуть - я детализировать не буду.
> ну, для нетката надо, как минимум, иметь лишний открытый порт в файрволле.пускай он сам отмазки придумывает, не подсказывай
> А куда "красивый динамичный" засунуть - я детализировать не буду.куда и зачем и что в этом плохого?
> ну, для нетката надо, как минимум, иметь лишний открытый порт в файрволле.для ssh тоже, но мне не жалко - просто не воспринимаю я netcat как способ передачи файлов.
И, наверное, ничего не хочу знать о том, как работают люди, у которых при наличии ssh доступа к хосту, в голове всплывает netcat для "скопировать файлик". (ну вот наверное да - выбирать шифрование под задачу они точно не умеют)> А куда "красивый динамичный" засунуть - я детализировать не буду.
я там в красках описал, как оно на самом деле устроено, тебе еще больше захочется его туда засунуть ;-)
ssh и так везде есть, там порт один хрен как-то открывается.
> ssh и так везде естьты явно не тамагочил vmware. Есть-то он есть, но при попытке его включить загорается красивый жельтий фак.
> там порт один хрен как-то открывается.
ровно в том же месте, где можно и любой другой порт открыть. И никакой тебе автоматики - запуск sshd никак не влечет открытия ему портов, идешь и вручную разрешаешь.
> Так и запишем: 1. netcat не осилен; 2. виртуалки на какой-то дрянинеткат на, хм, esxi, точно-точно есть? ;-)
Стоит ли гонять гигабайтный образ без хотя бы минимального контроля целостности, вопрос отдельный (хм, и md5 там, оказывается, тоже нет?)> запускаются, которая даже upload в красивом динамичном web-интерфейсе не может.
может. over ssl, и cipher выбираешь не ты. В случае esxi - windows only через странный кривой плагин, который наверное вот в новом-модном фуфлофоксе завтра отвалится. (download без этих ограничений, но, разумеется, тоже ssl)
Мне, как правило, проще и быстрее использовать scp (или таки настраивать ftpd у себя, но безопасность неодобряэ).
(а, хотя, хрен там - это ж vcenter, если б его не было, наверное вообще не было бы такой фичи в наличии)И, собственно, что, это единственный случай, когда надо перегнать по сети что-то не совсем мелкое, и при этом мы не боимся его показать страшным-престрашным хакерам?
Я-то его вспомнил ровно потому, что именно этот процесс именно мне часто приходится ждать.
> неткат на, хм, esxi, точно-точно есть? ;-)
> Стоит ли гонять гигабайтный образ без хотя бы минимального контроля целостности, вопрос
> отдельный (хм, и md5 там, оказывается, тоже нет?)Говоришь они в VmWare настолько ненавидят своих пользователей, что приложили усилия для сборки busybox без netcat и md5sum? Сомневаюсь. Попробуй nc, ncat.
С другой стороны почему бы и нет. Общеизвестно, что для юзеров проприетари страдание -- нормальное и привычное состояние души. Поэтому про удобный интерфейс, аплоад, бэкап и другие естественные потребности не будем упоминать лишний раз.
а, точно, это ж линукс, там md5sum должен быть.> Поэтому про удобный интерфейс, аплоад, бэкап и другие естественные потребности не будем
> упоминать лишний раз.как только героические девелоперы непроприетари распутают свои шнурки и осилят написать что-то аналогичное - мы немедленно на него перейдем. А пока у нас есть работающая проприетарь и неработающий с числом процессоров >1 сетевой драйвер в поделке имени оракла (не говоря уже о том, что какой там, в жо, удобный интерфейс, ЭТО в страшном сне должно сниться, с названием бинаря в mixed case), управляемой через интуитивно-приятный php-интерфейс, потому что все остальные в ней интерфейсы вообще к удаленному управлению непригодны.
Так что дома мне проще, по старинке, подсунуть в esxi свой sshd с 'none' - пока еще кое-как удается его собирать, чем ковыряться с неткатом.
Удалённые X-ы, LTSP, ...
Чтобы работало нормально приходится за каждый такт бороться - жаль arcfour.
Возможно, алгоритм слабоват в текущих реалиях, но в контролируемом окружении (L2 ACL + огорожено всё что нужно) - это вполне годная вещь была. Удалённые графические приложения с ним летали.
> Удалённые X-ы, LTSP, ...
> Чтобы работало нормально приходится за каждый такт бороться - жаль arcfour.серьезно? Мне казалось, там главное rtt
> жаль аркфору, быстрый был.
> А что сейчас самое быстрое ??если не аппаратный aes - то chacha20
Спасибо, запомню на будущее.
Самое печальное, что оно еще и в одно ядро упирается. А так есть вроде патчики с нуль-шифром.
> Самое печальное, что оно еще и в одно ядро упирается. А так
> есть вроде патчики с нуль-шифром.ага, знаем мы эти патчики - времен sshd версии 4.0, до "героичных выпиливателей".
Но я бы все же советовал blowfish - он достаточно быстр, чтобы упираться в сетевуху и диски, а не процессор, на хоть немного приличном железе, и есть везде, кроме тех мест, куда успеют добраться последние новые-модные поделки. А контроль целостности (в отличие от ненужношифрования) иметь полезно.
А что за SFTP и как им пользоваться? Клиент какой должен быть? Firefox сможет качать с SFTP?
> А что за SFTP и как им пользоваться? Клиент какой должен быть?
> Firefox сможет качать с SFTP?https://duckduckgo.com/?q=man+sftp Но, если ты спрашиваешь, то тебе не надо.
Ясно, очередной ненужный комбайн. Dropbear пора штатно ставить вместо этого systemd-opensshd
Кстати, а все правильно прочитали вот это:
"Режим включается [брюки превращаются] и реализован целиком на стороне клиента (может работать со старыми версиями sshd)." ?В переводе это значит вот что: думая, что дал юзеру (всевозможными способами ограниченный) ssh на свой хост, ты автоматически дал ему socks прокси на своем хосте. (вероятно, отключается там же где и остальные прокси, но и над этим ребятки тоже работают)
Пламенный превед лохам, заменяющим ftp на sftp, не обложившись по периметру ни колючкой, ни минными полями, ни рвами с крокодилами на худой конец.
(hetznerам привет, кстати)