Come posso disabilitare la crittografia su openssh?

Sto riscontrando problemi di prestazioni usando la combinazione openssh (server) e putty (client) per usare un webproxy remoto. Vorrei disabilitare la crittografia e testare i risultati per vedere se fa la differenza. Come lo posso fare? C'è qualcosa che posso modificare in sshd_config. Sono molto nuovo con openssh.

Qualsiasi altra idea sarà apprezzata.

Ho sostanzialmente impostato il mio IE per utilizzare le calze 127.0.0.1 come proxy. Collego il mio mastice al mio server openssh a casa e voilà - sono in grado di navigare in Internet attraverso quello. Tuttavia, è incredibilmente lento anche se so di avere una connessione veloce a casa mia (ad esempio ftp funziona a oltre 50Kbyte / sec.

Senza ricompilare nulla, non posso farlo per quanto ne so. Puoi comunque passare ad ARC4 o Blowfish che sono assurdamente veloci su hardware moderno.

La prestazione MIGLIORE (per quanto riguarda i cicli di clock) che puoi ottenere è con l'aggiunta

compression no

Puoi farlo cambiando

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

a

ciphers         arcfour,blowfish-cbc

Se vuoi spremere qualche prestazione extra a rischio di incompatibilità puoi cambiare

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

a

macs  hmac-md5-96

Se pensi ancora che questo sia un sovraccarico eccessivo, puoi tornare alla v1 o semplicemente fare una VPN standard.

A meno che il client o il server non siano drasticamente sottodimensionati, dubiterei fortemente che sia la crittografia a causare problemi di prestazioni. Io uso un "-D 8080" ssh proxy SOCKS regolarmente e non hanno mai accorto di nulla, ma una molto lieve rallentamento.

Una cosa da controllare è vedere qual è la latenza tra il client e il server. Se si tratta di una connessione molto latente, si vedrebbero sicuramente scarse prestazioni sul tunnel quando si utilizza HTTP, senza riscontrare problemi di prestazioni con FTP. Una volta che è in corso un trasferimento FTP, la latenza non ha molta importanza, ma con HTTP, hai a che fare con pagine Web che possono avere 50 o più handshake HTTP individuali che devono avvenire. Le connessioni ad alta latenza rallenteranno davvero questo processo e renderanno la navigazione insopportabile.

Quindi, comunque, le raccomandazioni fatte da Zephyr Pellerin sono valide. Se pensi davvero che sia la crittografia a causare il problema in tutti i modi, passa a un codice diverso. Suggerirei di esaminare prima la latenza, poiché sembra essere un candidato molto più probabile.

Questo thread mi ha fatto fare i miei benchmark e ho scoperto che le prestazioni variano non solo in base a diversi cifrari / MAC, ma fanno anche la differenza tra i dati che stai inviando, quali CPU sono coinvolti e come è impostata la rete.

Quindi IMO la cosa giusta da fare è eseguire i tuoi test e trovare le migliori impostazioni per la tua situazione.

Se qualcuno è interessato, ecco i risultati dei miei test confrontando un server guidato da Intel E5506 con un 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

Ma tra i primi 10, i risultati completi possono essere trovati qui .

Sono stato in grado di compilare sshd / ssh con la cifra 'none' con l'aiuto di questo post: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=24559#58

È un post molto vecchio, ma devi apportare 3 lievi modifiche al file di codice sorgente cipher.c. Quindi ricompilare il codice 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:

Inoltre, il nonecodice dovrà essere aggiunto al tuo/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

I collegamenti sottostanti ti aiuteranno a ottenere i sorgenti ssh per i sistemi Debian e Ubuntu:

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

Ringraziamo Dean Gaudet per essere fantastico

Secondo questo bellissimo post sul blog

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

Consiglio di impostare le seguenti cifre. Assicurati anche che la compressione sia disattivata se desideri le migliori prestazioni su LAN. Si noti che questo è possibile rischio per la sicurezza, utilizzare solo su LAN protette (ad es. In casa, ecc.).

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

Modifica la prima riga per elencare i tuoi IP nella tua LAN. Puoi anche fornire nomi host (separati da spazio). Questo ti offre le migliori prestazioni scp su LAN.

Se si desidera provare un tunnel completamente non crittografato e non compresso, è possibile provare a utilizzare qualcosa di simile rinetdper inoltrare i dati anziché SSH. Ciò eliminerebbe gli extra SSH mentre offriva un semplice tunnel binario sicuro per le connessioni TCP.

Quando dici di avere una connessione veloce a casa, sei sicuro che sia veloce in entrambe le direzioni? Molte connessioni domestiche sono molto asimmetriche (ad esempio la mia ADSL domestica è ~ 11Mit a valle e ~ 1,5Mbit a monte e molte sono peggio di così, alcune posso citare da connessioni di amici / famiglia: 7M / 0.4M, 19M / 1.3M, 20M / 0,75 M, ...). Ricorda che se stai usando home come proxy i dati devono passare attraverso il tuo link in entrambi i modi, quindi si sposteranno al meglioalla velocità più bassa a valle e a monte e hai anche un po 'di latenza extra da considerare. Inoltre, il tuo ISP potrebbe limitare deliberatamente la comunicazione a monte (coperta o selettivamente in modo tale che cose come la posta elettronica e i siti Web selezionati selezionati non siano interessati) come un modo per scoraggiare le persone che eseguono server / proxy dai loro collegamenti domestici, anche se questo è relativamente raro.

Ho appena fatto test approfonditi su questo, e la suite di cifratura che ha prodotto il rendimento più alto era aes-128-ctr con MAC umac64. Su una macchina a 4 core da 3,4 GHz ho visto quasi 900 MByte / sec tramite localhost (per eliminare i colli di bottiglia della rete per motivi di benchmarking)

Se hai davvero bisogno di così tante prestazioni, vuoi il SSH più recente e possibilmente le patch HPN-SSH .

Questa è un'opzione SSH lato client che ho usato per la connessione SSH a dispositivi di fascia bassa:

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

Nessun codice è nativamente supportato nelle recenti versioni di OpenSSH. Tuttavia, dal 7.6, OpenSSH ha rimosso il supporto SSHv1 ed etichettato la cifra "nessuna" per l'utilizzo interno.

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

Quindi hai bisogno di patch e ricompilazione sia per il server che per il lato client.

#define CFLAG_INTERNAL      0