Доступен (http://lists.mindrot.org/pipermail/openssh-unix-announce/201...) выпуск OpenSSH 6.7 (http://www.openssh.com/), открытой реализации клиента и сервера для работы по протоколам SSH (1.3, 1.5 и 2.0) и SFTP. Из наиболее важный улучшений можно отметить поддержку сборки с LibreSSL, возможность проброса Unix domain сокетов, начало выноса функциональности OpenSSH в отдельную библиотеку, прекращение поддержки tcpwrapper, возможность возобновления прерванных загрузок в sftp.Из заметных улучшений можно отметить:
- В ssh и sshd добавлена поддержка (http://25thandclement.com/~william/projects/streamlocal.html) проброса Unix domain сокетов через SSH-туннель, что позволяет перенаправить обращение к удалённому TCP-порту на локальный Unix domain сокет и наоборот, или соединить через ssh-туннель два Unix domain сокета. Например, для соединения СУБД PostgreSQL через SSH-туннель к локальному Unix domain сокету можно использовать команду "ssh -L/tmp/.s.PGSQL.5432:mydatabase.net:5432 someserver.com" или можно пробросить соединения клиентов к удалённому серверу на локальный сервер - "ssh -R/var/run/mysql.sock:/var/run/mysql.sock -R127.0.0.1:3306:/var/run/mysql.sock somehost";- Началась значительная внутренняя переработка, целью которой является вынос частей OpenSSH в отдельную библиотеку. В настоящее время уже проведён рефакторинг кода, связанного с парсингом, обработкой ключей и KRL. Так как API ещё не стабилизирован библиотека не поставляется в обособленном виде, но после завершения работы её можно будет использовать для задействования функциональности OpenSSH в других продуктах;
- Прекращена поддержка запуска с использованием tcpwrapper-ов и libwrap, так как конфигурации с лишними прослойками потенциально могут быть подвежены атаке ShellShock (http://www.opennet.me/opennews/art.shtml?num=40667);
- Предлагаемый в sshd по умолчанию набор шифров и MAC переработан в плане удаления небезопасных алгоритмов. В частности, по умолчанию теперь отключены шифры CBC и arcfour, при этом их поддержку можно вернуть путём явного указания через директивы Ciphers и MACs в sshd_config;- В sftp добавлена поддержка возобновления прерванных загрузок;- В ssh и ssh-keygen для ключей ED25519 добавлена поддержка DNS-записей SSHFP;- В sshd_config добавлена опция PermitUserRC для управления запуском ~/.ssh/rc, повторяющая опцию no-user-rc из файла authorized_keys;- В ssh для директив LocalCommand и ControlPath добавлена новая escape-последовательность %C, которая раскрывается в утикальный идентификатор, формируемый как хэш из имени локального хоста, удалённого пользователя, удалённого хоста и номера порта;- При выводе ошибки "Too many authentication failures" теперь указывается информация о пользователей, адресах, портах и протоколе;- Для подвергнутого рефакторингу кода добавлены unit и fuzz тесты, которые автоматически запускаются при выволнении "make tests" для переносимой версии OpenSSH;- Улучшения, специфичные для переносимой версии OpenSSH:
- Добавлена поддержка сборки с использованием переносимой версии LibreSSL (http://www.opennet.me/opennews/art.shtml?num=40184);- При сборке с OpenSSL в качестве минимально поддерживаемой версии теперь используется openssl 0.9.8f;- В скрипт инициализации opensshd.init добавлена поддержка генерации ключей ed25519;- В sftp-server добавлена возможность использования prctl() для блокирования доступа к /proc/self/{mem,maps}.
URL: http://lists.mindrot.org/pipermail/openssh-unix-announce/201...
Новость: http://www.opennet.me/opennews/art.shtml?num=40767
> В ssh и sshd добавлена поддержка проброса Unix domain сокетов через SSH-туннель...наконец-то!
Это типа чтобы stunnel не ставить?
> Это типа чтобы stunnel не ставить?или socket, или socat, или netcat, или.... Уф.
Проброс сокетов - круто. Остальное внутренние изменения, не очень интересно.
>В sftp добавлена поддержка возобновления прерванных загрузок.Это полезная фича.
Интересно. Обычно для SSH тонеля к PostgreSQL я исполняю такую команду:ssh -fNg -L 5433:127.0.0.1:5432 отдаленныйсервер
Иногда случается что связь теряется с отдаленным сервером и не смотря на изменения в sshd конфигурации (сколько сесии быть "alive") все равно выключается. Дело в том, что эта связь нужна для синхронизации базы данных на отдаленном сервере с локальной б.д. Я изначально создал crontab скрипт для автоматического выполнения синхронизации, но в связи с тем что иногда ssh связь теряется, теряется связь с отдаленной базой данных и скрипт зацикливается вечно пытаясь соеденится и это влияет на /tmp директорию т.к. создается застойный процесс.
Значит, согласно статье, эта новая версия OpenSSH как-то сможет держать ssh связь более постоянно?
Нет.
https://mosh.mit.edu/
Mosh не поддерживает проброс портов.
Должно быть две директивы.ClientAliveInterval 30
ClientAliveCountMax 1000
man autossh
autossh хорошая вещь! В генте говорит: Automatically restart SSH sessions and tunnels, имменно то что надо :)
При копировании больших файлов на хорошем канале очень помогал -o Ciphers=arcfour128 -o Compression=no , чтобы не грузило проц (одно ядро). Теперь придется в конфиги лазить?
чача вообще проц грузит?Host *
Ciphers chacha20-poly1305@openssh.com,aes128-ctr
> чача вообще проц грузит?Что за чача? Я тебя не понимаю.
Если копировать гигов тридцать на гигабитном канале - копирование может затянуться надолго из-за того, что упирается в производительность одного ядра. Смена шифра снижает нагрузку, ну, процентов на 30, может.
Хотя сейчас подумал что можно сделать сплит и в несколько потоков копирнуть.
Пробуй оба способа-o Ciphers=chacha20-poly1305@openssh.com -o Compression=no
-o Ciphers=chacha20-poly1305@openssh.com -o Compression=yes -o CompressionLevel=1
arcfour128 был самым быстрым шифром на старых процессорах. На современных уже быстрее aes128.На Intel(R) Xeon(R) E5-2620 v2 @ 2.10GHz (современный, есть AES-NI в но в openssh вроде не используется):
время на копирование тестового файла:
arcfour128 - 4.776 sec
aes128-ctr - 3.669 sec
chacha20-poly1305 - 6.570 secНа Intel(R) Xeon(R) E5335 @ 2.00GHz (не очень свежий)
arcfour128 - 8.117 sec
aes128-ctr - 9.912 sec
chacha20-poly1305 - 11.131 secВозможно всё дело в разнице размеров L1/L2 кешей...
> Возможно всё дело в разнице размеров L1/L2 кешей...Говорят помогает выставление в GCC флагов под малый обьем таких кешей
--param l1-cache-size
--param l1-cache-line-size
--param l2-cache-size
> При копировании больших файлов на хорошем канале очень помогал -o Ciphers=arcfour128 -o
> Compression=no , чтобы не грузило проц (одно ядро). Теперь придется в
> конфиги лазить?Да.
Или можно попробовать blowfish.
a режим "Perfect forward secrecy" в OpenSSH есть? Если есть, то как его использовать?
> a режим "Perfect forward secrecy" в OpenSSH есть? Если есть, то как его использовать?Не напрягаясь.
http://lmgtfy.com/?q=Perfect+forward+secrecy+openssh
""[...] SSH v2 normally uses Diffie-Hellman key exchange to set up the session keys, which inherently provides perfect forward security [...]
__ http://utcc.utoronto.ca/~cks/space/blog/tech/SshForwardSecrecy
Это как-то информация на строннем сайте. А вот на родном сайте OpenSSH информации не густо и та в стандартах сторонней ораганизации.
http://lmgtfy.com/?q=forward+secrecy+site%3Aopenssh.org
> Это как-то информация на строннем сайте. А вот на родном сайте OpenSSH
> информации не густо и та в стандартах сторонней ораганизации.
> http://lmgtfy.com/?q=forward+secrecy+site%3Aopenssh.orgНу, тогда _никому верить нельзя. Себе можно. Исходники и том Шнайера в руки -- и на баррикады. </pfs>
http://lwn.net/Articles/572926/
---А почему Шнайер молчит про такой замечательный маркетинговый кундштюк? [Наливает из графина.]
В общем мало используют FPS?. А если и используют, то вырастает в разы нагрузка на сервера.
Как можно самому посмотреть и убедится, что и клиент и сервер используют FPS?
а что, scp по–прежнему пробелы в путях и именах не хаваетъ?
осиль кавычки - и будет хавать