Como posso desativar a criptografia no openssh?

Estou tendo problemas de desempenho usando a combinação openssh (servidor) e putty (cliente) para usar um proxy remoto. Gostaria de desativar a criptografia e testar os resultados para ver se isso faz alguma diferença. Como eu posso fazer isso? Existe alguma coisa que eu possa modificar no sshd_config. Eu sou muito novo no openssh.

Quaisquer outras ideias seriam apreciadas.

Basicamente, configurei meu IE para usar as meias 127.0.0.1 como proxy. Conecto minha massa ao meu servidor openssh em casa e pronto - sou capaz de navegar na Internet através disso. No entanto, é incrivelmente lento, mesmo sabendo que tenho uma conexão rápida com minha casa (o ftp, por exemplo, funciona acima de 50Kbytes / s.

Sem recompilar nada, isso não pode ser feito até onde sei. No entanto, você pode alternar para o ARC4 ou o Blowfish, que são absurdamente rápidos no hardware moderno.

O melhor desempenho (no que diz respeito aos ciclos do relógio) que você obtém é o acréscimo

compression no

Você pode fazer isso alterando

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

para

ciphers         arcfour,blowfish-cbc

Se você deseja obter um desempenho extra com risco de incompatibilidade, pode alterar

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

para

macs  hmac-md5-96

Se você ainda acha que isso é demais, pode reverter para a v1 ou apenas fazer uma VPN padrão.

A menos que o cliente ou o servidor seja drasticamente fraco, duvido muito que seja a criptografia que está causando seus problemas de desempenho. Eu uso um "D 8080" procuração ssh meias regularmente e têm nada nunca percebeu, mas um muito ligeiro abrandamento.

Uma coisa a verificar é ver qual é a latência entre seu cliente e o servidor. Se for uma conexão muito latente, você certamente verá um desempenho ruim no túnel ao usar HTTP, sem observar problemas de desempenho com o FTP. Depois que uma transferência FTP está em andamento, a latência não importa, mas com o HTTP, você está lidando com páginas da web que podem ter 50 ou mais handshakes HTTP individuais que precisam acontecer. As conexões de alta latência vão realmente atrasar esse processo e tornar a navegação insuportável.

Enfim, as recomendações que Zephyr Pellerin fez são sólidas. Se você realmente acha que é a criptografia que está causando o problema a todos, mude para uma cifra diferente. Eu sugiro olhar primeiro para a latência, porém, pois isso parece ser um candidato muito mais provável.

Essa discussão me fez fazer meus próprios benchmarks e descobri que o desempenho varia não apenas por cifra / MAC diferente, mas também faz diferença que dados você está enviando, quais CPUs estão envolvidas e como a rede é configurada.

Portanto, a IMO deve fazer seus próprios testes e encontrar as melhores configurações para sua situação.

Se alguém estiver interessado, eis os resultados dos meus testes comparando um servidor Intel E5506 com um 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

Mas apenas no 'top 10', os resultados completos podem ser encontrados aqui .

Consegui compilar sshd / ssh com a cifra 'none' com a ajuda deste post: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=24559#58

É um post muito antigo, mas você precisa fazer 3 pequenas modificações no arquivo de código-fonte cipher.c. Em seguida, recompile o código 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:

Além disso, a nonecifra precisará ser adicionada ao seu/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

Os links abaixo ajudarão você a obter o código ssh para os sistemas Debian e Ubuntu:

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

Agradecemos a Dean Gaudet por ser incrível

De acordo com este post muito bom

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

Eu recomendo configurar as seguintes cifras. Verifique também se a compactação está desativada, se você deseja o melhor desempenho na LAN. Observe que este é um possível risco à segurança, use apenas em LAN segura (por exemplo, em casa, etc.).

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

Modifique a primeira linha para listar seus próprios IPs na sua LAN. Você também pode fornecer nomes de host (separados por espaço). Isso fornece o melhor desempenho de scp na LAN.

Se você quiser experimentar um túnel completamente não criptografado e descompactado, tente usar algo como rinetdencaminhar os dados em vez do SSH. Isso eliminaria os extras do SSH e ainda ofereceria um túnel binário seguro para conexões TCP.

Quando você diz que possui uma conexão rápida em casa, tem certeza de que é rápida nas duas direções? Muitas conexões domésticas são muito assimétricas (minha ADSL doméstica, por exemplo, é ~ 11Mit a jusante e ~ 1,5Mbit a montante e muitas são piores que isso, algumas citações de amigos / conexões familiares: 7M / 0,4M, 19M / 1,3M, 20M / 0,75M, ...). Lembre-se de que, se você estiver usando o lar como proxy, os dados deverão passar pelo seu link nos dois sentidos, para que se movam na melhor das hipótesesnas velocidades mais baixas a jusante e a montante e você também tem um pedaço de latência extra para levar em consideração. Além disso, seu ISP pode deliberadamente limitar a comunicação upstream (geral ou seletiva, para que coisas como email e sites populares selecionados não sejam afetados) como uma maneira de desencorajar as pessoas que executam servidores / proxies a partir de seus links domésticos, embora isso seja relativamente raro.

Acabei de fazer testes extensivos sobre isso, e o conjunto de cifras que produziu a maior taxa de transferência foi o aes-128-ctr com o umac64 MAC. Em uma máquina de 3,4 GHz e 4 núcleos, vi quase 900 MBytes / s através do host local (para eliminar os gargalos da rede em prol do benchmarking)

Se você realmente precisa de tanto desempenho, deseja os mais novos SSH e, possivelmente, os patches HPN-SSH .

Esta é uma opção SSH do lado do cliente que usei para conexão SSH com dispositivos low-end:

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

Nenhuma cifra é suportada nativamente nas versões recentes do OpenSSH. No entanto, desde a versão 7.6, o OpenSSH removeu o suporte ao SSHv1 e rotulou a cifra "none" para uso interno.

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

Então você precisa aplicar patches e recompilar para o servidor e o cliente.

#define CFLAG_INTERNAL      0