Как я могу отключить шифрование на openssh?

У меня проблемы с производительностью при использовании комбинации openssh (сервер) и putty (клиент) для использования удаленного веб-прокси. Я хотел бы отключить шифрование и проверить результаты, чтобы увидеть, если это имеет значение. Как я могу это сделать? Есть что-нибудь, что я могу изменить в sshd_config. Я очень новичок в openssh.

Любые другие идеи будут оценены.

Я в основном настроил свой IE для использования 127.0.0.1 носков в качестве прокси. Я подключаю свою замазку к моему openssh серверу дома и вуаля - я могу просматривать интернет через это. Тем не менее, он невероятно медленный, хотя я знаю, что у меня есть быстрое соединение с моим домом (например, ftp работает со скоростью выше 50 Кбайт / с.

Без перекомпиляции ничего нельзя сделать, насколько я знаю. Однако вы можете переключиться на ARC4 или Blowfish, которые нелепо быстры на современном оборудовании.

ЛУЧШУЮ производительность (с точки зрения тактовых циклов) можно получить, добавив

compression no

Вы можете сделать это, изменив

ciphers         aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
                aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
                aes256-cbc,arcfour

в

ciphers         arcfour,blowfish-cbc

Если вы хотите выжать дополнительную производительность из-за риска несовместимости, вы можете изменить

macs  hmac-md5,hmac-sha1,umac-64@openssh.com,
      hmac-ripemd160,hmac-sha1-96,hmac-md5-96

в

macs  hmac-md5-96

Если вы все еще думаете, что это слишком много, вы можете вернуться к v1 или просто сделать стандартный VPN.

Если клиент или сервер не имеют значительных мощностей, я бы сильно сомневался в том, что именно шифрование вызывает проблемы с производительностью. Я регулярно использую ssh-прокси "-D 8080" и никогда не замечал ничего, кроме очень небольшого замедления.

Одна вещь, которую нужно проверить, это посмотреть, какова задержка между вашим клиентом и сервером. Если это очень латентное соединение, вы наверняка увидите низкую производительность по туннелю при использовании HTTP, но не увидите проблем с производительностью по FTP. Когда идет передача по FTP, задержка на самом деле не имеет значения, но с HTTP вы имеете дело с веб-страницами, которые могут иметь 50 или более отдельных HTTP-рукопожатий, которые должны произойти. Соединения с высокой задержкой действительно замедляют этот процесс и делают просмотр невыносимым.

Так или иначе, рекомендации, сделанные Зефиром Пеллером, являются обоснованными. Если вы действительно думаете, что именно шифрование вызывает их во что бы то ни стало, переключитесь на другой шифр. Я бы посоветовал сначала изучить латентность, так как это выглядит гораздо более вероятным кандидатом.

Этот поток заставил меня сделать свои собственные тесты, и я обнаружил, что производительность зависит не только от разных шифров / MAC, но и от того, какие данные вы отправляете, какие процессоры задействованы и как настроена сеть.

Так что IMO - это то, что нужно сделать, чтобы запустить свои собственные тесты и найти лучшие настройки для вашей ситуации.

Если кому-то интересно, вот результаты моих тестов, сравнивающих Сервер на базе Intel E5506 с Raspberry Pi:

--
-- Intel Xeon E5506(4 x 2.13 GHz), 50MB Random binary Data over localhost
--

cipher                      mac                        speed
---------------------------------------------------------------
aes192-cbc                  hmac-sha1                    50MB/s
arcfour256                  hmac-sha2-512              49.9MB/s
arcfour                     hmac-ripemd160             49.8MB/s
aes256-cbc                  hmac-sha1-96               49.7MB/s
aes128-cbc                  hmac-sha1-96               49.7MB/s
aes192-cbc                  hmac-sha1                  48.9MB/s
arcfour                     hmac-ripemd160@openssh.com 48.8MB/s
aes256-cbc                  hmac-sha1-96               48.8MB/s
arcfour                     hmac-ripemd160@openssh.com 48.7MB/s
aes128-cbc                  hmac-sha1                  48.4MB/s


--
-- Raspberry PI B+, 10MB Random binary over localhost
--

cipher                      mac                        speed
---------------------------------------------------------------
arcfour256                  umac-64@openssh.com        2.75MB/s
arcfour128                  umac-64@openssh.com        2.74MB/s
arcfour                     umac-64@openssh.com        2.63MB/s
arcfour                     umac-64@openssh.com        2.54MB/s
arcfour                     hmac-md5-96                2.36MB/s
arcfour128                  hmac-md5                   2.34MB/s
arcfour256                  hmac-md5                   2.34MB/s
arcfour256                  umac-64@openssh.com        2.33MB/s
arcfour256                  hmac-md5-96                2.28MB/s
arcfour256                  hmac-md5-96                2.22MB/s

Но только в «10 лучших», полные результаты можно найти здесь .

Я смог скомпилировать sshd / ssh с шифром 'none' с помощью этого поста: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=24559#58

Это очень старый пост, но вы должны сделать 3 небольших изменения в файле исходного кода cipher.c. Затем перекомпилируйте код sshd / ssh.

@@ -175,7 +175,7 @@
    for ((p = strsep(&cp, CIPHER_SEP)); p && *p != '\0';
        (p = strsep(&cp, CIPHER_SEP))) {
        c = cipher_by_name(p);
-       if (c == NULL || c->number != SSH_CIPHER_SSH2) {
+       if (c == NULL || (c->number != SSH_CIPHER_SSH2 && c->number != SSH_CIPHER_NONE)) {
            debug("bad cipher %s [%s]", p, names);
            xfree(ciphers);
            return 0;
@@ -343,6 +343,7 @@
    int evplen;

    switch (c->number) {
+   case SSH_CIPHER_NONE:
    case SSH_CIPHER_SSH2:
    case SSH_CIPHER_DES:
    case SSH_CIPHER_BLOWFISH:
@@ -377,6 +378,7 @@
    int evplen = 0;

    switch (c->number) {
+   case SSH_CIPHER_NONE:
    case SSH_CIPHER_SSH2:
    case SSH_CIPHER_DES:
    case SSH_CIPHER_BLOWFISH:

Кроме того, noneшифр должен быть добавлен к вашему/etc/ssh/sshd_config

Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr,none

Ссылки ниже помогут вам получить исходный код ssh для систем Debian и Ubuntu:

• /ubuntu//a/345198/54228
• https://www.debian.org/doc/manuals/apt-howto/ch-sourcehandling.en.html

Благодарим Дина Годе за то, что он потрясающий

Согласно этому очень хорошему сообщению в блоге

http://blog.famzah.net/2010/06/11/openssh-ciphers-performance-benchmark/

Я рекомендую установить следующие шифры. Также убедитесь, что сжатие отключено, если вы хотите наилучшую производительность в локальной сети. Обратите внимание, что это возможный риск безопасности, используйте только в защищенной локальной сети (например, дома и т. Д.).

# cat ~/.ssh/config
Host 192.168.1.*
    Compression no
    Ciphers arcfour256,arcfour128,arcfour,blowfish-cbc,aes128-cbc,aes192-cbc,cast128-cbc,aes256-cbc

Измените первую строку, чтобы перечислить ваши собственные IP-адреса в вашей локальной сети. Вы также можете указать имена хостов (разделенные пробелом). Это дает вам лучшую производительность scp в локальной сети.

Если вы хотите попробовать полностью незашифрованный и несжатый туннель, вы можете попробовать использовать что-то вроде rinetdпересылки данных вместо SSH. Это исключило бы дополнительные возможности SSH, в то же время предлагая простой двоичный безопасный туннель для соединений TCP.

Когда вы говорите, что у вас есть быстрое соединение дома, вы уверены, что оно быстрое в обоих направлениях? Многие домашние соединения очень асимметричны (мой домашний ADSL, например, ~ 11Mit вниз по течению и ~ 1.5Mbit вверх по течению, и многие из них хуже, некоторые, которые я могу процитировать от друзей / семейных подключений: 7M / 0.4M, 19M / 1.3M, 20M / 0,75М, ...). Помните, что если вы используете home в качестве прокси-сервера, данные должны пройти по вашей ссылке в обоих направлениях, поэтому они будут двигаться в лучшем случаена самых медленных из ваших скоростей нисходящего и восходящего потоков, и у вас есть кусок дополнительной задержки, чтобы учесть также. Также ваш интернет-провайдер может намеренно ограничить общение в восходящем потоке (либо общее, либо выборочное, чтобы не затрагивать такие вещи, как электронная почта и избранные популярные веб-сайты) как способ отговорить людей, использующих серверы / прокси-серверы, от своих домашних ссылок, хотя это относительно редко.

Я только что провел обширное тестирование по этому вопросу, и набор шифров, обеспечивающий самую высокую пропускную способность, был aes-128-ctr с umac64 MAC. На 4-ядерном компьютере с тактовой частотой 3,4 ГГц скорость локального хоста составила почти 900 МБ / с (для устранения узких мест в сети для оценки производительности)

Если вам действительно нужна такая высокая производительность, вам нужен новейший SSH и, возможно, патчи HPN-SSH .

Это одна из опций SSH на стороне клиента, которую я использовал для подключения SSH к устройствам низкого уровня:

ssh -c none -m hmac-md5-96 -oKexAlgorithms=curve25519-sha256@libssh.org ....

Ни один шифр изначально не поддерживается в последних версиях OpenSSH. Однако, начиная с 7.6, OpenSSH удалил поддержку SSHv1 и пометил шифр «нет» для внутреннего использования.

#define CFLAG_NONE      (1<<3)
#define CFLAG_INTERNAL      CFLAG_NONE /* Don't use "none" for packets */

Затем вам нужно установить исправления и перекомпилировать как на стороне сервера, так и на стороне клиента.

#define CFLAG_INTERNAL      0