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

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.

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,[email protected],
      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.

À 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.

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                     [email protected] 48.8MB/s
aes256-cbc                  hmac-sha1-96               48.8MB/s
arcfour                     [email protected] 48.7MB/s
aes128-cbc                  hmac-sha1                  48.4MB/s


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

cipher                      mac                        speed
---------------------------------------------------------------
arcfour256                  [email protected]        2.75MB/s
arcfour128                  [email protected]        2.74MB/s
arcfour                     [email protected]        2.63MB/s
arcfour                     [email protected]        2.54MB/s
arcfour                     hmac-md5-96                2.36MB/s
arcfour128                  hmac-md5                   2.34MB/s
arcfour256                  hmac-md5                   2.34MB/s
arcfour256                  [email protected]        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 .

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,[email protected],aes128-ctr,aes192-ctr,aes256-ctr,none

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

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

Nous remercions Dean Gaudet d'être génial

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.

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.

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 .

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 [email protected] ....

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