Wie kann ich die Verschlüsselung bei openssh deaktivieren?

Ich habe Leistungsprobleme bei der Verwendung von OpenSSH (Server) und Putty (Client) zur Verwendung eines Remote-Webproxys. Ich möchte die Verschlüsselung deaktivieren und die Ergebnisse testen, um festzustellen, ob dies einen Unterschied macht. Wie kann ich das machen? Gibt es etwas , was ich in der ändern kann sshd_config. Ich bin sehr neu in openssh.

Alle anderen Ideen wäre dankbar.

Ich habe meinen IE so eingestellt, dass er 127.0.0.1-Socken als Proxy verwendet. Ich verbinde meinen Kitt zu Hause mit meinem openssh-Server und voila - dadurch kann ich im Internet surfen. Es ist jedoch unglaublich langsam, obwohl ich weiß, dass ich eine schnelle Verbindung zu meinem Zuhause habe (FTP funktioniert beispielsweise mit über 50 KByte / s).

Ohne eine Neukompilierung ist dies meines Wissens nicht möglich. Sie können jedoch auf ARC4 oder Blowfish umsteigen, die auf moderner Hardware unglaublich schnell sind.

Die beste Leistung (was die Taktzyklen betrifft), die Sie erzielen können, ist das Hinzufügen

compression no

Sie können dies durch Ändern tun

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

zu

ciphers         arcfour,blowfish-cbc

Wenn Sie zusätzliche Leistung auf Inkompatibilitätsrisiko ausnutzen möchten, können Sie dies ändern

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

zu

macs  hmac-md5-96

Wenn Sie immer noch der Meinung sind, dass dies zu viel Aufwand ist, können Sie zu Version 1 zurückkehren oder einfach ein Standard-VPN erstellen.

Wenn der Client oder Server nicht drastisch unterlastet ist, würde ich stark bezweifeln, dass es die Verschlüsselung ist, die Ihre Leistungsprobleme verursacht. Ich verwende ein „-D 8080“ ssh SOCKS - Proxy regelmäßig und habe nie etwas bemerkt aber eine sehr leichte Abschwächung.

Eine Sache, die Sie überprüfen müssen, ist die Latenz zwischen Ihrem Client und dem Server. Wenn es sich um eine sehr latente Verbindung handelt, wird bei Verwendung von HTTP mit Sicherheit eine schlechte Leistung über den Tunnel erzielt, während bei FTP keine Leistungsprobleme auftreten. Sobald eine FTP-Übertragung ausgeführt wird, spielt die Latenz keine Rolle mehr. Bei HTTP handelt es sich jedoch um Webseiten, auf denen möglicherweise 50 oder mehr einzelne HTTP-Handshakes ausgeführt werden müssen. Verbindungen mit hoher Latenz verlangsamen diesen Prozess erheblich und machen das Surfen unerträglich.

Die Empfehlungen, die Zephyr Pellerin ausgesprochen hat, sind jedenfalls gut. Wenn Sie wirklich glauben, dass es die Verschlüsselung ist, die das Problem auf alle Fälle verursacht, wechseln Sie zu einer anderen Verschlüsselung. Ich würde jedoch vorschlagen, zuerst die Latenz zu untersuchen, da dies ein viel wahrscheinlicherer Kandidat zu sein scheint.

In diesem Thread habe ich meine eigenen Benchmarks erstellt und festgestellt, dass die Leistung nicht nur durch verschiedene Verschlüsselungen / MACs variiert, sondern auch einen Unterschied macht, welche Daten Sie senden, welche CPUs beteiligt sind und wie das Netzwerk eingerichtet ist.

IMO ist daher das Richtige, wenn Sie Ihre eigenen Tests durchführen und die besten Einstellungen für Ihre Situation finden.

Wenn jemand interessiert ist, sind hier die Ergebnisse meiner Tests, die einen Intel E5506-gesteuerten Server mit einem Himbeer-Pi vergleichen:

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

Aber nur unter den 'Top 10' finden Sie hier die vollständigen Ergebnisse .

Mit Hilfe dieses Beitrags konnte ich sshd / ssh mit der Chiffre 'none' kompilieren: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=24559#58

Es ist ein sehr alter Beitrag, aber Sie müssen 3 geringfügige Änderungen an der Quellcodedatei cipher.c vornehmen. Kompilieren Sie dann den sshd / ssh-Code neu.

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

Außerdem muss die noneChiffre zu Ihrer hinzugefügt werden/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

Die folgenden Links helfen Ihnen dabei, SSH-Quellcode für Debian- und Ubuntu-Systeme zu erhalten:

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

Wir danken Dean Gaudet, dass er großartig ist

Laut diesem sehr schönen Blogbeitrag

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

Ich empfehle die folgenden Chiffren einzurichten. Stellen Sie außerdem sicher, dass die Komprimierung deaktiviert ist, wenn Sie die beste Leistung im LAN erzielen möchten. Bitte beachten Sie, dass dies ein mögliches Sicherheitsrisiko darstellt. Verwenden Sie es nur in einem sicheren LAN (z. B. zu Hause usw.).

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

Ändern Sie die erste Zeile, um Ihre eigenen IPs in Ihrem LAN aufzulisten. Sie können auch Hostnamen angeben (durch Leerzeichen getrennt). Dies gibt Ihnen die beste SCP-Leistung im LAN.

WENN Sie einen völlig unverschlüsselten und unkomprimierten Tunnel ausprobieren möchten, können Sie versuchen, rinetddie Daten mit etwas anderem als SSH weiterzuleiten. Dies würde die SSH-Extras einschränken und gleichzeitig einen einfachen, binärsicheren Tunnel für TCP-Verbindungen bieten.

Wenn Sie sagen, dass Sie zu Hause eine schnelle Verbindung haben, sind Sie sicher, dass diese in beide Richtungen schnell ist? Viele Heimanschlüsse sind sehr asymetrisch (mein Heim-ADSL ist zum Beispiel ~ 11Mit Downstream und ~ 1,5Mbit Upstream und viele sind schlechter als das, einige kann ich von Freunden / Familienanschlüssen zitieren: 7M / 0,4M, 19M / 1,3M, 20M / 0,75 M, ...). Denken Sie daran, dass die Daten, wenn Sie home als Proxy verwenden, in beide Richtungen über Ihren Link geleitet werden müssen, damit sie sich im besten Fall bewegenBei der langsamsten Ihrer Downstream- und Upstream-Geschwindigkeiten haben Sie eine gewisse zusätzliche Latenz, die Sie ebenfalls berücksichtigen müssen. Ihr Internetdienstanbieter drosselt möglicherweise absichtlich die Upstream-Kommunikation (entweder pauschal oder selektiv, damit E-Mails und ausgewählte beliebte Websites nicht beeinträchtigt werden), um Benutzer davon abzuhalten, Server / Proxys von ihren Home-Links zu entfernen. Dies ist jedoch relativ selten.

Ich habe dies gerade ausgiebig getestet, und die Cipher Suite mit dem höchsten Durchsatz war aes-128-ctr mit umac64 MAC. Auf einem 4-Core-Rechner mit 3,4 GHz habe ich fast 900 MB / s durch localhost gesehen (um Netzwerkengpässe für das Benchmarking zu beseitigen)

Wenn Sie wirklich so viel Leistung benötigen, benötigen Sie das neueste SSH und möglicherweise die HPN-SSH- Patches.

Dies ist eine clientseitige SSH-Option, die ich für die SSH-Verbindung zu Low-End-Geräten verwendet habe:

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

In neueren OpenSSH-Versionen wird keine Verschlüsselung nativ unterstützt. Seit 7.6 hat OpenSSH jedoch die SSHv1-Unterstützung entfernt und "keine" Verschlüsselung für den internen Gebrauch angegeben.

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

Dann müssen Sie für die Server- und Client-Seite patchen und neu kompilieren.

#define CFLAG_INTERNAL      0