Openssh'ta şifrelemeyi nasıl devre dışı bırakabilirim?

Uzak bir web proxy kullanmak için openssh (sunucu) ve macun (istemci) kombinasyonunu kullanırken performans sorunları yaşıyorum. Şifrelemeyi devre dışı bırakmak ve bir fark yaratıp yaratmadığını görmek için sonuçları test etmek istiyorum. Bunu nasıl yapabilirim? İçinde değiştirebileceğim bir şey var mı sshd_config. Openssh için çok yeniyim.

Başka herhangi bir fikir takdir edilecektir.

Temel olarak IE'mi, vekil olarak 127.0.0.1 çorap kullanacak şekilde ayarlamıştım. Macunumu evde openssh sunucuma bağlarım ve işte - İnternette gezebiliyorum. Ancak, evimle hızlı bir bağlantım olduğunu bilmeme rağmen inanılmaz derecede yavaş (örneğin ftp 50Kbyte / sn'nin üzerinde çalışıyor.

Bir şey yeniden derlemeden, bildiğim kadarıyla yapılamaz. Bununla birlikte, modern donanımda akıl almaz derecede hızlı olan ARC4 veya Blowfish'e geçebilirsiniz.

EN İYİ performans (saat döngüleri söz konusu olduğunda) alabileceğiniz bir artış

compression no

Bunu değiştirerek yapabilirsiniz.

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

için

ciphers         arcfour,blowfish-cbc

Uyumsuzluk riski altında bazı ekstra performans sıkmak istiyorsanız, değiştirebilirsiniz

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

için

macs  hmac-md5-96

Hala bunun çok fazla bir yük olduğunu düşünüyorsanız, v1'e geri dönebilir ya da sadece standart bir VPN yapabilirsiniz.

İstemci veya sunucu büyük ölçüde güçsüz olmadığı sürece, performans sorunlarınıza neden olan şifrelemeden şüpheliyim. Düzenli olarak "-D 8080" ssh proxy çorap kullanıyorum ve çok hafif bir yavaşlama dışında hiçbir şey fark etmedim .

Kontrol edilecek bir şey, müşterinizle sunucu arasındaki gecikmenin ne olduğunu görmektir. Çok gizli bir bağlantıysa, HTTP kullanırken FTP ile performans sorunlarını görmüyorsanız, tünel üzerinde düşük performans göreceksiniz. Bir FTP aktarımı devam ettikten sonra gecikme önemli değil, ancak HTTP ile olması gereken 50 veya daha fazla bireysel HTTP anlaşması olabilecek web sayfalarıyla uğraşıyorsunuz. Yüksek gecikmeli bağlantılar bu işlemi yavaşlatır ve taramayı dayanılmaz hale getirir.

Her neyse, Zephyr Pellerin tarafından yapılan öneriler sağlam. Gerçekten de soruna neden olan şifrelemenin gerçekten olduğunu düşünüyorsanız, farklı bir şifreye geçin. İlk önce gecikmeye bakmayı öneriyorum, çünkü bu daha muhtemel bir aday gibi görünüyor.

Bu konu bana kendi ölçütlerimi koyuyor ve Performansın sadece farklı şifre / MAC ile değişmediğini, hangi veriyi gönderdiğinizi, hangi CPU'ların dahil olduğunu ve ağ kurulumunun nasıl bir fark yarattığını fark ettim.

IMO yapılacak doğru şey kendi testlerinizi yapmak ve durumunuz için en iyi ayarları bulmak.

Biriyle ilgileniyorsanız, Intel E5506 ile çalışan bir sunucuyu Ahududu Pi ile karşılaştıran testlerimin sonuçları:

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

Ancak ony 'en iyi 10', tam sonuçlar burada bulunabilir .

Bu yazının yardımı ile sshd / ssh kodunu 'none' ile derleyebildim: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=24559#58

Çok eski bir gönderi, ancak kaynak kod dosyası cipher.c için 3 küçük değişiklik yapmanız gerekiyor. Sonra sshd / ssh kodunu yeniden derleyin.

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

Ayrıca, noneşifrenin size eklenmesi gerekecek/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

Aşağıdaki bağlantılar Debian ve Ubuntu sistemleri için ssh kaynağı almanıza yardımcı olacaktır:

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

Dean Gaudet'e harika olduğu için teşekkür ederiz

Bu çok güzel blog yazısına göre

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

Aşağıdaki şifreleri ayarlamanızı öneririm. Ayrıca LAN üzerinde en iyi performansı istiyorsanız, sıkıştırmanın kapalı olduğundan emin olun. Lütfen bunun olası bir güvenlik riski olduğuna dikkat edin, yalnızca güvenli LAN'da kullanın (örn. Evde vb.).

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

LAN’ınızda kendi IP’lerinizi listelemek için ilk satırı değiştirin. Ayrıca ana bilgisayar adları da sağlayabilir (boşlukla ayrılmış). Bu size LAN üzerindeki en iyi scp performansını verir.

Tamamen şifrelenmemiş ve sıkıştırılmamış bir tünel denemek istiyorsanız rinetd, verileri SSH yerine iletmek gibi bir şey kullanmayı deneyebilirsiniz . Bu, TCP bağlantıları için düz bir ikili-emniyetli tünel sunarken, SSH ekstralarını sınırlandırır.

Evde hızlı bir bağlantınız olduğunu söylerken, her iki yönde de hızlı olduğundan emin misiniz? Pek çok ev bağlantısı çok asimetriktir (örneğin, evim ADSL'si ~ 11Mit aşağı akış yönünde ve ~ 1.5Mbit yukarı akış yönündedir ve çoğu bundan daha kötüdür, bazıları arkadaşlardan / aile bağlantılarından alıntı yapabilirim: 7M / 0.4M, 19M / 1.3M, 20M / 0,75 M, ...). Eve bir vekil olarak kullanıyorsanız, verinin bağlantınızın her iki yolundan da gitmesi gerektiğini unutmayın .aşağı ve yukarı akış hızlarınız arasında en düşük hızda ve siz de hesaba katmak için fazladan bir gecikme süresine sahipsiniz. Ayrıca, ISS'niz kasıtlı olarak yukarı yöndeki iletişimi (örtü veya seçici olarak e-posta ve seçili popüler web siteleri gibi etkilenmeyecek şekilde) etkileyebilir), sunucuları / proxy'leri çalışan kişilerin ana linklerinden uzak tutmaya teşvik etmelerinin bir yolu olarak görülebilir.

Bu konuda geniş kapsamlı testler yaptım ve en yüksek verimi sağlayan şifre paketi umac64 MAC ile aes-128-ctr idi. 4 çekirdekli 3.4GHz bir makinede localhost aracılığıyla neredeyse 900 MB / sn gördüm (kıyaslama amacıyla ağ darboğazlarını ortadan kaldırmak için)

Gerçekten de bu kadar performansa ihtiyacınız varsa, en yeni SSH'yi ve muhtemelen HPN-SSH yamalarını istersiniz .

Bu, düşük uçlu cihazlara SSH bağlantısı için kullandığım bir istemci tarafı SSH seçeneği:

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

Hiçbiri şifre, son OpenSSH versiyonlarında yerel olarak desteklenmiyor. Bununla birlikte, 7.6'dan beri, OpenSSH SSHv1 desteğini kaldırdı ve dahili kullanım için "none" şifresini etiketledi.

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

O zaman hem sunucu hem de müşteri tarafı için yama yapmanız ve yeniden derlemeniz gerekir.

#define CFLAG_INTERNAL      0