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

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

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

Ничего не перекомпилировав, это не может быть сделано насколько я знаю. Можно однако переключиться на ARC4 или Шифр, который нелепо быстр на современных аппаратных средствах.

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

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.

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

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

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

Согласно этому прекрасному сообщению в блоге

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 в локальной сети.

I was able to compile sshd/ssh with cipher 'none' with the help of this post: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=24559#58

It's a very old post, but you have to make 3 slight modifications to the source code file cipher.c. Then recompile the sshd/ssh code.

@@ -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:

Also, the none cipher will need to be added to your /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

The links below will help you get ssh source for Debian and Ubuntu systems:

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

Credit to Dean Gaudet for being awesome

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

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

Hierdie draad het my eie maatstawwe laat doen en ek het uitgevind dat die prestasie nie net verskil deur verskillende cipher / MAC nie, dit maak ook 'n verskil watter data u stuur, watter SVE's betrokke is en hoe netwerk is ingestel.

IMO is dus die regte ding om u eie toetse uit te voer en die beste instellings vir u situasie te vind.

As iemand belangstel, is hier die uitslae van my toetse wat 'n Intel E5506-bediener bedien met a 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

Maar net die 'top 10', die volledige resultate kan hier gevind word .

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

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

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

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

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

#define CFLAG_INTERNAL      0