Jak mogę wyłączyć szyfrowanie w openssh?

Mam problemy z wydajnością, używając kombinacji openssh (serwer) i putty (klient) do korzystania ze zdalnego webproxy. Chciałbym wyłączyć szyfrowanie i przetestować wyniki, aby zobaczyć, czy to robi różnicę. Jak mogę to zrobić? Czy mogę coś zmodyfikować w sshd_config. Jestem bardzo nowy w openssh.

Wszelkie inne pomysły będą mile widziane.

Zasadniczo ustawiłem moją IE, aby używała skarpetek 127.0.0.1 jako serwera proxy. Łączę mój kit z moim serwerem openssh w domu i voila - dzięki temu mogę przeglądać internet. Jest jednak niesamowicie wolny, mimo że wiem, że mam szybkie połączenie z moim domem (na przykład ftp działa z prędkością powyżej 50 KB / s.

Bez ponownej kompilacji nie da się tego zrobić, o ile mi wiadomo. Możesz jednak przejść na ARC4 lub Blowfish, które są absurdalnie szybkie na nowoczesnym sprzęcie.

NAJLEPSZA wydajność (jeśli chodzi o cykle zegara) wzrost, jaki można uzyskać, to dodawanie

compression no

Możesz to zrobić, zmieniając

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

do

ciphers         arcfour,blowfish-cbc

Jeśli chcesz wycisnąć trochę dodatkowej wydajności z ryzykiem niezgodności, możesz to zmienić

macs  hmac-md5,hmac-sha1,[email protected],
      hmac-ripemd160,hmac-sha1-96,hmac-md5-96

do

macs  hmac-md5-96

Jeśli nadal uważasz, że to zbyt duże obciążenie, możesz wrócić do wersji 1 lub po prostu zrobić standardową sieć VPN.

O ile klient lub serwer nie są drastycznie słabe, bardzo wątpię, że to szyfrowanie powoduje problemy z wydajnością. Regularnie używam proxy ssh „-D 8080” i nigdy nie zauważyłem niczego poza bardzo niewielkim spowolnieniem.

Jedną rzeczą do sprawdzenia jest sprawdzenie, jakie jest opóźnienie między klientem a serwerem. Jeśli jest to bardzo ukryte połączenie, z pewnością zobaczysz niską wydajność w tunelu podczas korzystania z HTTP, nie zauważając problemów z wydajnością FTP. Gdy trwa przesyłanie FTP, opóźnienie nie ma tak naprawdę znaczenia, ale w przypadku HTTP masz do czynienia ze stronami internetowymi, które mogą mieć 50 lub więcej indywidualnych uzgadnień HTTP, które muszą nastąpić. Połączenia o dużym opóźnieniu naprawdę spowolnią ten proces i sprawią, że przeglądanie będzie nie do zniesienia.

Tak czy inaczej, zalecenia Zephyr Pellerin są trafne. Jeśli naprawdę sądzisz, że to szyfrowanie powoduje je z całą pewnością, przełącz się na inny szyfr. Proponuję jednak najpierw przyjrzeć się opóźnieniom, ponieważ wydaje się, że jest to znacznie bardziej prawdopodobny kandydat.

Wątek ten sprawił, że wykonałem własne testy porównawcze i dowiedziałem się, że wydajność różni się nie tylko w zależności od innego szyfru / MAC, ale także wpływa na to, jakie dane wysyłasz, jakie procesory są zaangażowane i jak skonfigurowana jest sieć.

IMO powinien zatem uruchomić własne testy i znaleźć najlepsze ustawienia dla swojej sytuacji.

Jeśli ktoś jest zainteresowany, oto wyniki moich testów porównujących serwer z procesorem Intel E5506 z 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

Ale tylko „10 najlepszych”, pełne wyniki można znaleźć tutaj .

Byłem w stanie skompilować sshd / ssh z szyfrowaniem „none” za pomocą tego postu: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=24559#58

To bardzo stary post, ale musisz wprowadzić 3 niewielkie modyfikacje pliku kodu źródłowego cipher.c. Następnie ponownie skompiluj kod 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:

Również noneszyfr należy dodać do twojego/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

Poniższe linki pomogą ci zdobyć źródło ssh dla systemów Debian i Ubuntu:

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

Podziękowania dla Deana Gaudeta za bycie niesamowitym

Według tego bardzo fajnego posta na blogu

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

Zalecam ustawienie następujących szyfrów. Upewnij się również, że kompresja jest wyłączona, jeśli chcesz uzyskać najlepszą wydajność w sieci LAN. Należy pamiętać, że jest to możliwe zagrożenie bezpieczeństwa, używaj tylko w bezpiecznej sieci LAN (np. W domu itp.).

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

Zmodyfikuj pierwszy wiersz, aby wyświetlić własne adresy IP w sieci LAN. Możesz także podać nazwy hostów (oddzielone spacją). Zapewnia to najlepszą wydajność scp w sieci LAN.

JEŚLI chcesz wypróbować całkowicie nieszyfrowany i nieskompresowany tunel, możesz spróbować użyć czegoś takiego jak rinetdprzekazywanie danych zamiast SSH. Zminimalizowałoby to dodatki SSH, a jednocześnie oferowałby prosty tunel binarnie bezpieczny dla połączeń TCP.

Kiedy mówisz, że masz szybkie połączenie w domu, czy jesteś pewien, że jest ono szybkie w obu kierunkach? Wiele połączeń domowych jest bardzo asymetrycznych (na przykład mój domowy ADSL to ~ 11Mit poniżej i ~ 1,5Mbit powyżej, a wiele jest gorszych, niektóre z nich mogę zacytować od znajomych / połączeń rodzinnych: 7M / 0,4M, 19M / 1,3M, 20M / 0,75 mln ...). Pamiętaj, że jeśli używasz domu jako serwera proxy, dane muszą przejść przez Twój link w obie strony, więc w najlepszym wypadku będą się przenosićprzy najwolniejszej z twoich prędkości pobierania i wysyłania, a także masz fragment dodatkowego opóźnienia, aby również wziąć pod uwagę. Również twój dostawca usług internetowych może celowo ograniczać komunikację początkową (kocową lub selektywną, aby nie wpływać na takie rzeczy, jak poczta elektroniczna i wybrane popularne strony internetowe), aby zniechęcić osoby zarządzające serwerami / serwerami proxy do swoich łączy domowych, chociaż jest to stosunkowo rzadkie.

Właśnie przeprowadziłem szeroko zakrojone testy w tym zakresie, a pakiet szyfrów, który przyniósł największą przepustowość, to aes-128-ctr z umac64 MAC. Na 4-rdzeniowej maszynie 3,4 GHz widziałem prawie 900 MB / s przez localhost (aby wyeliminować wąskie gardła w sieci ze względu na testy porównawcze)

Jeśli naprawdę potrzebujesz tak dużej wydajności, potrzebujesz najnowszej wersji SSH i ewentualnie łatek HPN-SSH .

Jest to jedna opcja SSH po stronie klienta, której użyłem do połączenia SSH z urządzeniami klasy niskiej:

ssh -c none -m hmac-md5-96 [email protected] ....

Żaden szyfr nie jest natywnie obsługiwany w najnowszych wersjach OpenSSH. Jednak od wersji 7.6 OpenSSH usunął obsługę SSHv1 i oznaczył szyfr „brak” do użytku wewnętrznego.

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

Następnie potrzebujesz łatania i ponownej kompilacji zarówno po stronie serwera, jak i klienta.

#define CFLAG_INTERNAL      0