The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Релиз OpenSSH 7.6

04.10.2017 11:33

После шести месяцев разработки представлен релиз OpenSSH 7.6, открытой реализации клиента и сервера для работы по протоколам 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 для кода разбора открытых ключей и верификации сигнатур.


  1. Главная ссылка к новости (http://lists.mindrot.org/piper...)
  2. OpenNews: Из OpenSSH удалена поддержка протокола SSH1
  3. OpenNews: Релиз OpenSSH 7.5
  4. OpenNews: Релиз OpenSSH 7.4
  5. OpenNews: Обход защиты OpenSSH, препятствующей определению наличия пользователя
  6. OpenNews: Обновление OpenSSH 7.2p2 с устранением уязвимости в режиме X11Forwarding
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/47324-openssh
Ключевые слова: openssh
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (54) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Ivan1986 (?), 12:08, 04/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    вот accept-new это реально полезно
     
     
  • 2.10, Аноним (-), 14:57, 04/10/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Воистину так!
     
  • 2.11, Товарищ майор (?), 14:58, 04/10/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Мы тоже одобряем.
     

  • 1.2, souryogurt (ok), 12:15, 04/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    > В клиент ssh добавлена директива RemoteCommand, через которую можно на уровне файла конфигурации задать команду для выполнения на удалённой стороне сразу после входа

    Вангую волну червей использующих эту фишку

     
     
  • 2.5, AlexYeCu_not_logged (?), 12:30, 04/10/2017 [^] [^^] [^^^] [ответить]  
  • +5 +/
    >Вангую волну червей использующих эту фишку

    Да с чего бы?
    Во-первых, подобный функционал давно используется.
    Во-вторых, коль по ssh уже зашли на хост, данная возможность ничего не прибавит и не убавит.

     
     
  • 3.7, souryogurt (ok), 12:47, 04/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Да с чего бы?
    > Во-вторых, коль по ssh уже зашли на хост, данная возможность ничего не прибавит и не убавит.

    Ну, наверное, я что-то не так понимаю. Я представил себе обычного непривилегированного пользователя, машина которого была как-либо заражена в первый раз. Например, веб-мастер. Его ssh конфиг меняется, и добавляется команда которая при логине на хост (например на stage, production, а еще лучше CI сервер проектов над которыми он работает) добавляет аналогичную команду которая меняет ssh конфиг авторизованного пользователя. Червь может и не знать пароль от серверов, пользователь введет его самостоятельно при подключении. Он также может залогиниться куда-нибудь как root.
    Допустим он залогинился на CI чтобы поменять настройки. на CI ssh конфиг поменялся. В следующий раз когда CI будет логиниться на stage или production, процесс повторится. Возможно такое?

     
     
  • 4.15, angra (ok), 17:34, 04/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Возможно конечно, извращаться можно по разному, а можно не ждать у моря погоды, а сразу пройтись по всем хостам, к которым юзер когда-либо подключался, и сделать там своё темное дело. Так и быстрее и меньше следов.
     
     
  • 5.17, EHLO (?), 18:16, 04/10/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Возможно конечно, извращаться можно по разному, а можно не ждать у моря
    > погоды, а сразу пройтись по всем хостам, к которым юзер когда-либо
    > подключался, и сделать там своё темное дело. Так и быстрее и
    > меньше следов.

    Если юзер по паролю логинится или ключ зашифрован и агент не запущен, тогда в этом RemoteCommand есть скрытый смысл, чувак прав.

     
     
  • 6.32, noname.htm (ok), 10:06, 05/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Червь меняет вызов ssh через алиас на свой враппер, который просто перехватит пароль к серверу и ключу - вуаля. Если машина скомпрометирована, то лучший путь - переустановка с нуля, т.к. наворотить можно при желании так, что пол жизни разбираться будешь.
     
  • 4.18, anonimus (?), 19:27, 04/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Звучит правдоподобно.
    Но судя по описанию, в таком случае интерактивной сессии не случится. Смотреть надо.
     
  • 2.8, нах (?), 13:43, 04/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Вангую волну червей использующих эту фишку

    авторы червей - грамотные ребята, и давно ее заимплементили самостоятельно. Но да, теперь им можно расслабиться и поддерживать одним куском кода меньше ;-)

     

  • 1.3, Аномномномнимус (?), 12:19, 04/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Есть механизм обновления в ~/.ssh/authorized_keys старого публичного ключа на новый? Например я сгенерил себе новый ключ, загрузил оба ключа в агента для авторизации на "старых" и "новых" хостах и хочу чтобы по мере обхода на "старых" хостах (со старым ключом) в момент входа старый ключ заменялся на новый.
     
     
  • 2.4, нах (?), 12:29, 04/10/2017 [^] [^^] [^^^] [ответить]  
  • –4 +/
    агент _ничего_ не знает о твоем публичном ключе.
    А хосты ничего не знают о том, что он "cтарый".
    учи матчасть, еще один sed-неосилятор.
     
  • 2.6, Аноним (-), 12:34, 04/10/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    authorized_keys на сервере описывает ключи, по которым сервер узнаёт вас (клиента). Если ключ не подойдет, то ты не сможешь даже залогиниться на сервере, не то что обновить authorized_keys. Но если старый ключ ещё есть, то можно написать скрипт, который будет с помощью старого ключа логиниться на сервер и подменять публичный ключ на новый в authorized_keys. man ssh.
     
     
  • 3.12, Crazy Alex (ok), 16:34, 04/10/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ну собственно вопрос товарища  был - есть ли такое готовое, чтобы самому не писать. Как по мне - правильный вопрос, подобный менеджмент должен быть в коробке.
     
     
  • 4.14, забыл_пароль_от_тигар (?), 17:23, 04/10/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    подобный "менеджмент" состоит из:
    * импорта в ssh-agent обоих ключей (старый+новый)
    * ssh-copy-id (или таки sed, как местный Прозревший под ником толи "пох" толи "нах" вещает в комментах которой уже новости)
    * ssh host sed '/pattern to match(old_key)/d'
    делаешь алиасом для ssh этот враппер и получаешь то, что изначально и хотел афтар
    либо, к примеру, каким ансиблом/циклом на шелл это дело фигачишь
     
     
  • 5.21, Аномномномнимус (?), 20:47, 04/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да, sed, awk, ansible, ещё вагон костылей и скрипты поверх всего этого зоопарка. Разумеется для каждой ОС свой персональный набор костылей, о своими багами и приколами вплоть до "все ключи убиты, ни один не добавился, а авторизация по паролю запрещена" вместо функционала, который нужен из коробки, наравне с ssh-copy-id. Если ты не согласен, то не пользуйся ssh-copy-id, пользуйся scp и костылями по ручному добавлению в authorized_keys всякого (так жы веселей)
     
     
  • 6.33, забыл_пароль_от_тигар (?), 10:08, 05/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    твои патчи ("функционала, который нужен из коробки, наравне с ssh-copy-id") отвергают или где?
     
  • 2.9, Борщдрайвен бигдата (?), 14:26, 04/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    ssh-copy-id с авторизацией по старому ключу, нет?
     
     
  • 3.19, Аномномномнимус (?), 20:01, 04/10/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ssh-copy-id придётся каждый раз руками набирать, когда хостов много и они постоянно меняются, это лет за много лет безумно надоедает.
    К тому же ещё устаревший ключ нужно дропнуть.
     
     
  • 4.22, пох (?), 21:32, 04/10/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    шелл, оказывается, тоже ниасилен, как и sed? Ну понятно, виндyзятник до такой степени - должен страдать.
     
     
  • 5.23, Аномномномнимус (?), 21:47, 04/10/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Виндузятникам на эту фичу как правило плевать, потому что у них авторизация разруливается совсем иначе. Но ты продолжай рукоблудить-манкикодить на скриптах и конфигах, вдруг токсикоз пройдёт, полегчает
     
  • 4.50, Борщдрайвен бигдата (?), 17:33, 06/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > хостов много
    > они постоянно меняются
    > много лет

    Если за много лет в таком сценарии не освоен хоть поверхностно какой-нибудь ansible, то всё очень плохо.

     

  • 1.13, pfg21 (?), 16:44, 04/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    жаль аркфору, быстрый был.
    А что сейчас самое быстрое ??
     
     
  • 2.16, Stax (ok), 17:54, 04/10/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    aes128-gcm@openssh.com у меня выдает 500 МБ/сек (при копировании с localhost на localhost), это в полтора раза быстрее, чем arcfour в таком же тесте. Зачем он вам?
    (проц, конечно, с поддержкой AES-NI, но это сейчас даже в атомах есть несколько лет как)
     
     
  • 3.20, pfg21 (?), 20:41, 04/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    у меня есть файлопомойка на стареньком проце, тех времен когда о шифрации сильно не думали, точнее дурон  1ггц. он прекрасно работает, там валяетя синхронизируемая копия сд-карточки с телефона, куда периодически закидываю музон. требования к закрытости небольшие, а скорость никогда не помешает. я конечно утрирую, пофиг до скорости на таких задачках, но внутренний идеалист нажимает на жабу после такой картинки http://hsto.org/files/9b6/2b7/0a3/9b62b70a363d41d2a78f676b71a71218.png :)
     
     
  • 4.25, пох (?), 22:33, 04/10/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > требования к закрытости небольшие, а скорость никогда не помешает. я конечно
    > утрирую, пофиг до скорости на таких задачках

    э нет, это _твое_ время, а не машинное, которое _ты_ ждешь, пока оно докопирует.

    > но внутренний идеалист нажимает на жабу после такой картинки

    мой внутренний идеалист категорически против использования новых-модных версий openssh, сделанных неосиляторами для неосиляторов, чего и вашему желает.
    вплоть до ручного пакетирования чего-нибудь 5.3 на основе редхатовской сборки с ручным бэкпортом патчей и всерьез подумывания, не откопать ли обратно исходники последних версий ssh1.

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

     
  • 3.24, пох (?), 22:22, 04/10/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > (проц, конечно, с поддержкой AES-NI, но это сейчас даже в атомах есть
    > несколько лет как)

    у меня атом 2011го года - мне его в помойку нести, потому что ssh-вырежем-все-подряд-неписатели так решили?

    (понятно, что я проживу без этого архинужного апргейда еще лет десять, а потом либо шах, либо ишак, либо сам ходжа, но что прикажете делать тем, кому достанется именно эта версия?)

     
     
  • 4.26, Stax (ok), 22:35, 04/10/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Не хотите - не несите. А что, для остального (веб браузинг и тп) хватает, а вот скорости ssh прямо вот никак не хватает?

    Нашел под рукой древний Atom 2011 года (N2800). 1.86 Ghz, TDP 6.5W. Двухядерный даже! Никакого AES-NI и в помине нет, конечно. Выдает 27 МБ/с в aes256. Неплохо бы быстрее, но.. неужели это будет узким местом в каких-либо задачах под такой процессор?

     
     
  • 5.27, пох (?), 01:41, 05/10/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Не хотите - не несите. А что, для остального (веб браузинг и тп) хватает

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

    > Неплохо бы быстрее, но.. неужели это будет узким местом в каких-либо задачах под такой
    > процессор?

    ну вот хочешь ты скопировать побыстрому исошник на хранилку виртуалок, и бежать в другое место. Можно, конечно,заморочиться и настроить у себя ftpd. Потом залезть на хранилку и оттуда клиентом стащить. А можно просто запустить scp. Но с aes придется "немного" подождать. Примерно так вдвое больше, чем с blowfish, и втрое чем с none. none на хранилку возводить немного сложно. Исошника злым хакерам, разумеется, ни разу не жалко.
    А время - оно твое идет.

     
     
  • 6.28, Crazy Alex (ok), 01:55, 05/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Конкретно в данном случае - можно запустить копирование и убежать, на что там смотреть?

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

     
     
  • 7.37, пох (?), 14:46, 05/10/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Конкретно в данном случае - можно запустить копирование и убежать, на что там смотреть?

    прибежал, а оно, опа, отвалилось в процессе. Или места не хватило.
    А может неплохо было прежде чем убегать ,еще и инсталл оттуда дернуть?

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

    > А вообще - железа без аппаратной поддержки aes таки мало

    ну, я теперь имею железный аргумент на следующей работе требовать с начальства ноут поновее - а то на моем "i3-2350M" тоже как-то aes'ом не пахнет, но вообще-то таких вполне еще приличных X230 не так чтобы "мало". Мало более новых, и не всем дают. Он, конечно, в любом случае не такой дохлый как домашний атом, и тормозить, наверное, будет приемлемо (не буду мерять, чтоб не расстраиваться).

    > А пока эта версия распространение получит

    ох... твои б слова да Богу в уши, но, боюсь, через пару месяцев уже где-нибудь да напорешься.

     
     
  • 8.41, Crazy Alex (ok), 15:36, 05/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Да я ж не спорю, бывает Но чтобы это было значимо в плане потерь времени - сомн... текст свёрнут, показать
     
     
  • 9.44, пох (?), 17:56, 05/10/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    да я как-то особых страданий не испытываю, мне на нем не жабу отлаживать хотя, ... текст свёрнут, показать
     
  • 6.31, EHLO (?), 09:42, 05/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > ну вот хочешь ты скопировать побыстрому исошник на хранилку виртуалок, и бежать
    > в другое место. Можно, конечно,заморочиться и настроить у себя ftpd.

    Так и запишем: 1. netcat не осилен; 2. виртуалки на какой-то дряни запускаются, которая даже upload в красивом динамичном web-интерфейсе не может.


     
     
  • 7.34, Crazy Alex (ok), 11:19, 05/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ну, для нетката надо, как минимум, иметь лишний открытый порт в файрволле. А куда "красивый динамичный" засунуть - я детализировать не буду.
     
     
  • 8.36, EHLO (?), 13:22, 05/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    пускай он сам отмазки придумывает, не подсказывай куда и зачем и что в этом плох... текст свёрнут, показать
     
  • 8.40, пох (?), 14:59, 05/10/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    для ssh тоже, но мне не жалко - просто не воспринимаю я netcat как способ переда... текст свёрнут, показать
     
     
  • 9.42, Crazy Alex (ok), 15:39, 05/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    ssh и так везде есть, там порт один хрен как-то открывается ... текст свёрнут, показать
     
     
  • 10.43, пох (?), 17:50, 05/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    ты явно не тамагочил vmware Есть-то он есть, но при попытке его включить загора... текст свёрнут, показать
     
  • 7.38, пох (?), 14:55, 05/10/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Так и запишем: 1. netcat не осилен; 2. виртуалки на какой-то дряни

    неткат на, хм, esxi, точно-точно есть? ;-)
    Стоит ли гонять гигабайтный образ без хотя бы минимального контроля целостности, вопрос отдельный (хм, и md5 там, оказывается, тоже нет?)

    > запускаются, которая даже upload в красивом динамичном web-интерфейсе не может.

    может. over ssl, и cipher выбираешь не ты. В случае esxi - windows only через странный кривой плагин, который наверное вот в новом-модном фуфлофоксе завтра отвалится. (download без этих ограничений, но, разумеется, тоже ssl)
    Мне, как правило, проще и быстрее использовать scp (или таки настраивать ftpd у себя, но безопасность неодобряэ).
    (а, хотя, хрен там - это ж vcenter, если б его не было, наверное вообще не было бы такой фичи в наличии)

    И, собственно, что, это единственный случай, когда надо перегнать по сети что-то не совсем мелкое, и при этом мы не боимся его показать страшным-престрашным хакерам?
    Я-то его вспомнил ровно потому, что именно этот процесс именно мне часто приходится ждать.

     
     
  • 8.45, EHLO (?), 21:10, 05/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Говоришь они в VmWare настолько ненавидят своих пользователей, что приложили уси... текст свёрнут, показать
     
     
  • 9.47, пох (?), 15:36, 06/10/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    а, точно, это ж линукс, там md5sum должен быть как только героические девелопер... текст свёрнут, показать
     
  • 5.30, John (??), 09:12, 05/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Удалённые X-ы, LTSP, ...
    Чтобы работало нормально приходится за каждый такт бороться - жаль arcfour.
    Возможно, алгоритм слабоват в текущих реалиях, но в контролируемом окружении (L2 ACL + огорожено всё что нужно) - это вполне годная вещь была. Удалённые графические приложения с ним летали.
     
     
  • 6.39, пох (?), 14:55, 05/10/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Удалённые X-ы, LTSP, ...
    > Чтобы работало нормально приходится за каждый такт бороться - жаль arcfour.

    серьезно? Мне казалось, там главное rtt

     
  • 2.29, Crazy Alex (ok), 01:57, 05/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > жаль аркфору, быстрый был.
    > А что сейчас самое быстрое ??

    если не аппаратный aes - то chacha20

     
     
  • 3.35, pfg21 (ok), 11:23, 05/10/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Спасибо, запомню на будущее.
     
  • 2.46, Ананас (?), 09:24, 06/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Самое печальное, что оно еще и в одно ядро упирается. А так есть вроде патчики с нуль-шифром.
     
     
  • 3.48, пох (?), 15:42, 06/10/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Самое печальное, что оно еще и в одно ядро упирается. А так
    > есть вроде патчики с нуль-шифром.

    ага, знаем мы эти патчики - времен sshd версии 4.0, до "героичных выпиливателей".
    Но я бы все же советовал blowfish - он достаточно быстр, чтобы упираться в сетевуху и диски, а не процессор, на хоть немного приличном железе, и есть везде, кроме тех мест, куда успеют добраться последние новые-модные поделки. А контроль целостности (в отличие от ненужношифрования) иметь полезно.


     

  • 1.49, АнонимХ (ok), 16:36, 06/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А что за SFTP и как им пользоваться? Клиент какой должен быть? Firefox сможет качать с SFTP?
     
     
  • 2.51, Andrey Mitrofanov (?), 18:37, 06/10/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А что за SFTP и как им пользоваться? Клиент какой должен быть?
    > Firefox сможет качать с SFTP?

    https://duckduckgo.com/?q=man+sftp Но, если ты спрашиваешь, то тебе не надо.

     
     
  • 3.53, Аноним (-), 08:13, 07/10/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ясно, очередной ненужный комбайн. Dropbear пора штатно ставить вместо этого systemd-opensshd
     

  • 1.52, пох (?), 20:05, 06/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Кстати, а все правильно прочитали вот это:
    "Режим включается [брюки превращаются] и реализован целиком на стороне клиента (может работать со старыми версиями sshd)."  ?

    В переводе это значит вот что: думая, что дал юзеру (всевозможными способами ограниченный) ssh на свой хост, ты автоматически дал ему socks прокси на своем хосте. (вероятно, отключается там же где и остальные прокси, но и над этим ребятки тоже работают)

    Пламенный превед лохам, заменяющим ftp на sftp, не обложившись по периметру ни колючкой, ни минными полями, ни рвами с крокодилами на худой конец.
    (hetznerам привет, кстати)

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру