Comment puis-je désactiver le cryptage sur openssh?


21

J'ai des problèmes de performances en utilisant la combinaison openssh (serveur) et putty (client) pour utiliser un proxy Web distant. J'aimerais désactiver le cryptage et tester les résultats pour voir si cela fait une différence. Comment puis je faire ça? Y a-t-il quelque chose que je puisse modifier dans le sshd_config. Je suis très nouveau sur openssh.

Toute autre idée serait appréciée.

J'ai essentiellement configuré mon IE pour utiliser les chaussettes 127.0.0.1 comme proxy. Je connecte mon mastic à mon serveur openssh à la maison et le tour est joué - je peux naviguer sur Internet à travers cela. Cependant, c'est incroyablement lent même si je sais que j'ai une connexion rapide à ma maison (ftp par exemple fonctionne à plus de 50 Ko / sec.


2
C'est dommage que le patch rot13 ( miranda.org/~jkominek/rot13 ) n'ait jamais pris ...
Kenster

5
Je doute fortement que le cryptage utilisé par SSH soit la cause de votre connexion lente tant que votre serveur SSH ne fonctionne pas sur une montre-bracelet numérique de 1980.
joschi

Réponses:


17

Sans recompiler quoi que ce soit, cela ne peut pas être fait pour autant que je sache. Vous pouvez cependant passer à ARC4 ou Blowfish qui sont incroyablement rapides sur du matériel moderne.

La MEILLEURE performance que vous pouvez obtenir (en ce qui concerne les cycles d'horloge) consiste à ajouter

compression no

Vous pouvez le faire en modifiant

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

Si vous souhaitez réduire les performances supplémentaires au risque d'incompatibilité, vous pouvez modifier

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

à

macs  hmac-md5-96

Si vous pensez toujours que c'est trop de frais généraux, vous pouvez revenir à la v1 ou simplement faire un VPN standard.


3
Si votre installation OpenSSH (aux deux extrémités) est compatible avec la prise en charge du chiffrement "aucun", vous pouvez également le spécifier, mais cela va à l'encontre de l'objectif du shell sécurisé .
voretaq7

1
Pour les personnes inclinées en C parmi nous, vous pouvez ajouter {"none", SSH_CIPHER_NONE, 8, 0, 0, EVP_enc_null} à cipher.c dans le tableau de chiffrement.
ŹV -

3
Je pourrais également souligner que vous pouvez utiliser quelque chose comme socat ( dest-unreach.org/socat ) pour faire la même chose ET éviter tous les frais généraux du protocole SSH.
ŹV -

Je pense que umac-64 est le plus rapide de ces algorithmes mac.
James Reinstate Monica Polk

Le MD5 96 bits est incroyablement rapide dans tous les cas.
ŹV -

7

À moins que le client ou le serveur ne soit considérablement sous-alimenté, je doute fortement que ce soit le cryptage qui cause vos problèmes de performances. J'utilise régulièrement un proxy de chaussettes ssh "-D 8080" et je n'ai jamais rien remarqué sauf un très léger ralentissement.

Une chose à vérifier est de voir quelle est la latence entre votre client et le serveur. S'il s'agit d'une connexion très latente, vous verriez sûrement de mauvaises performances sur le tunnel lors de l'utilisation de HTTP, tout en ne voyant pas de problèmes de performances avec FTP. Une fois qu'un transfert FTP est en cours, la latence n'a pas vraiment d'importance, mais avec HTTP, vous avez affaire à des pages Web qui peuvent avoir au moins 50 prises de contact HTTP individuelles qui doivent se produire. Les connexions à latence élevée ralentiront vraiment ce processus et rendront la navigation insupportable.

Donc, de toute façon, les recommandations de Zephyr Pellerin sont valables. Si vous pensez vraiment que c'est le cryptage qui leur cause le problème, passez à un autre cryptage. Cependant, je suggérerais d'abord d'examiner la latence, car cela semble être un candidat beaucoup plus probable.


+1 pour cela ... les problèmes sont très peu susceptibles d'être le cryptage et vont très probablement être la connexion à votre hôte à la maison en premier lieu.
DaveG

16
Je souhaite que les gens cessent de dire que vous n'avez pas besoin de le faire et entament de longues discussions sur les avantages et les inconvénients de la surcharge de chiffrement (si ou pas), et essayez simplement de répondre à la question. Je ne vois pas de raison d'ajouter un chiffrement redondant pour ma tâche locale sur ma machine locale pour laquelle j'ai besoin au moins d'une authentification, mais travailler de localhost à localhost ne nécessite vraiment pas de chiffrement.
Marius

5
Ce n'est pas vrai, essayez de copier un gros fichier en utilisant scp sur un gig-ethernet. La charge Intel iCore 5 est de 80%.
lzap

@Izap> Mais il n'y a pas que le cryptage. Le transfert d'un fichier volumineux à l'aide de ftp(sans SSL) me donne également une charge de processeur de 20 à 40%. Je blâme le Gig-Ethernet bon marché nécessitant trop d'attention de la part du processeur.
spectres

Lorsque vous utilisez SSH pour l'envoi / la réception ZFS, le processeur est un goulot d'étranglement;)
Xdg

6

Ce fil m'a permis de faire mes propres tests de performance et j'ai découvert que les performances varient non seulement selon le chiffrement / MAC, mais également les données que vous envoyez, les processeurs impliqués et la configuration du réseau.

Donc, IMO la bonne chose à faire est d'exécuter vos propres tests et de trouver les meilleurs paramètres pour votre situation.

Si quelqu'un est intéressé, voici les résultats de mes tests comparant un serveur piloté par Intel E5506 avec 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

Mais seulement le «top 10», les résultats complets peuvent être trouvés ici .


les résultats sans le chiffrement «aucun» sont incomplets pour ce sujet. J'ai beaucoup de pogoplugv4 (version bras 800Mhz = lent) et ils rattachent souvent le cpu avec ssh. c'est pourquoi les gens recherchent le chiffrement nul. l'utilisation du processeur ssh / sshd à 100% signifie que ce n'est pas un problème de réseau! j'espère que je me souviens de revenir et de poster le résultat de chiffrement = aucun ...
user2420786

Avez-vous le script que vous utilisiez pour générer ces données? Je serais très intéressé par les performances des chiffrements actuels ( chacha20-poly1305@openssh.com) sur le matériel d'aujourd'hui.
Jakuje


3

J'ai pu compiler sshd / ssh avec le chiffrement 'none' à l'aide de ce post: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=24559#58

C'est un article très ancien, mais vous devez apporter 3 légères modifications au fichier de code source cipher.c. Recompilez ensuite le code 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:

De plus, le nonechiffre devra être ajouté à votre/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

Les liens ci-dessous vous aideront à obtenir la source ssh pour les systèmes Debian et Ubuntu:

Nous remercions Dean Gaudet d'être génial


2

D'après ce très beau billet de blog

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

Je recommande de configurer les chiffres suivants. Assurez-vous également que la compression est désactivée si vous souhaitez obtenir les meilleures performances sur le LAN. Veuillez noter qu'il s'agit d'un risque de sécurité possible, utilisez uniquement sur un LAN sécurisé (par exemple à la maison, etc.).

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

Modifiez la première ligne pour répertorier vos propres adresses IP dans votre réseau local. Vous pouvez également fournir des noms d'hôtes (séparés par un espace). Cela vous donne les meilleures performances scp sur LAN.


1

SI vous voulez essayer un tunnel complètement non chiffré et non compressé, vous pouvez essayer d'utiliser quelque chose comme rinetdpour transférer les données au lieu de SSH. Cela éliminerait les extras SSH tout en offrant un tunnel sûr binaire pour les connexions TCP.

Lorsque vous dites que vous avez une connexion rapide à la maison, êtes-vous sûr qu'elle est rapide dans les deux sens? De nombreuses connexions à domicile sont très asymétriques (mon ADSL à domicile par exemple est ~ 11Mit en aval et ~ 1,5Mbit en amont et beaucoup sont pires que cela, certaines que je peux citer d'amis / connexions familiales: 7M / 0,4M, 19M / 1,3M, 20M / 0,75 M, ...). N'oubliez pas que si vous utilisez la maison comme proxy, les données doivent passer par votre lien dans les deux sens, elles évolueront donc au mieux.à la vitesse la plus lente de vos vitesses en aval et en amont et vous avez également une part de latence supplémentaire à prendre en compte. De plus, votre FAI peut délibérément limiter la communication en amont (soit globale, soit de manière sélective afin que des éléments comme le courrier électronique et certains sites Web populaires ne soient pas affectés) comme un moyen de décourager les personnes utilisant des serveurs / mandataires de leurs liens domestiques, bien que cela soit relativement rare.


ssh est standard sur la plupart des machines. rinetd n'est pas sur certains, mais merci pour la suggestion.
Marius

alors vous devriez essayer netcat / nc
ThorstenS

0

Je viens de faire des tests approfondis à ce sujet, et la suite de chiffrement qui a donné le débit le plus élevé était aes-128-ctr avec umac64 MAC. Sur une machine à 3,4 cœurs à 3,4 GHz, j'ai vu près de 900 Mo / s via localhost (pour éliminer les goulots d'étranglement du réseau pour les besoins de l'analyse comparative)

Si vous avez vraiment besoin de tant de performances, vous voulez le dernier SSH, et peut-être les correctifs HPN-SSH .


0

Il s'agit d'une option SSH côté client que j'ai utilisée pour la connexion SSH aux appareils bas de gamme:

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

Aucun chiffrement n'est pris en charge nativement dans les versions récentes d'OpenSSH. Cependant, depuis la version 7.6, OpenSSH a supprimé la prise en charge SSHv1 et étiqueté «aucun» pour un usage interne.

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

Ensuite, vous devez corriger et recompiler à la fois côté serveur et côté client.

#define CFLAG_INTERNAL      0
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.