Bagaimana saya bisa menonaktifkan enkripsi pada openssh?

Saya mengalami masalah kinerja menggunakan kombinasi openssh (server) dan dempul (klien) untuk menggunakan proxy web jarak jauh. Saya ingin menonaktifkan enkripsi dan menguji hasilnya untuk melihat apakah ada bedanya. Bagaimana saya bisa melakukan itu? Apakah ada yang bisa saya ubah di sshd_config. Saya sangat baru di openssh.

Gagasan lain akan dihargai.

Saya pada dasarnya telah mengatur IE saya untuk menggunakan 127.0.0.1 kaus kaki sebagai proxy. Saya menghubungkan dempul saya ke server openssh saya di rumah dan voila - Saya dapat menjelajahi internet melalui itu. Namun, ini sangat lambat meskipun saya tahu saya memiliki koneksi cepat ke rumah saya (ftp misalnya berfungsi di atas 50Kbytes / detik.

Tanpa mengkompilasi ulang apa pun, itu tidak dapat dilakukan sejauh yang saya ketahui. Namun Anda dapat beralih ke ARC4 atau Blowfish yang sangat cepat pada perangkat keras modern.

Peningkatan kinerja TERBAIK (sejauh menyangkut siklus jam) yang bisa Anda dapatkan adalah dengan menambahkan

compression no

Anda dapat melakukan ini dengan mengubah

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

untuk

ciphers         arcfour,blowfish-cbc

Jika Anda ingin memeras kinerja ekstra dengan risiko ketidakcocokan, Anda dapat mengubahnya

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

untuk

macs  hmac-md5-96

Jika Anda masih berpikir ini terlalu banyak overhead, Anda bisa kembali ke v1 atau hanya melakukan VPN standar.

Kecuali jika klien atau server kekurangan daya secara drastis, saya sangat meragukan bahwa enkripsi yang menyebabkan masalah kinerja Anda. Saya menggunakan "-D 8080" ssh proxy kaus kaki secara teratur dan memiliki apa-apa tidak pernah diperhatikan tapi sangat perlambatan sedikit.

Satu hal yang perlu diperiksa adalah untuk melihat apa latensi antara klien Anda dan server. Jika itu koneksi yang sangat laten, Anda pasti akan melihat kinerja yang buruk di atas terowongan saat menggunakan HTTP, sementara tidak melihat masalah kinerja dengan FTP. Setelah transfer FTP sedang berlangsung, latensi tidak terlalu penting, tetapi dengan HTTP, Anda berurusan dengan halaman web yang mungkin memiliki 50 atau lebih jabat tangan HTTP individual yang perlu terjadi. Koneksi latensi tinggi akan sangat memperlambat proses ini dan membuat penelusuran menjadi tak tertahankan.

Jadi, rekomendasi yang dibuat Zephyr Pellerin masuk akal. Jika Anda benar-benar berpikir bahwa itu enkripsi yang menyebabkan masalah dengan segala cara, beralihlah ke cipher yang berbeda. Saya sarankan melihat latensi terlebih dahulu, karena itu tampaknya menjadi kandidat yang jauh lebih mungkin.

Utas ini membuat saya melakukan tolok ukur sendiri dan saya menemukan bahwa Performa bervariasi tidak hanya dengan cipher / MAC yang berbeda, tetapi juga membuat perbedaan data apa yang Anda kirim, CPU mana yang terlibat dan bagaimana jaringan diatur.

Jadi IMO hal yang benar untuk dilakukan adalah menjalankan tes Anda sendiri dan menemukan pengaturan terbaik untuk situasi Anda.

Jika seseorang tertarik, berikut adalah hasil pengujian saya membandingkan Server yang digerakkan Intel E5506 dengan 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

Tapi selain '10 besar', hasil lengkapnya dapat ditemukan di sini .

Saya dapat mengkompilasi sshd / ssh dengan cipher 'none' dengan bantuan posting ini: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=24559#58

Ini adalah posting yang sangat lama, tetapi Anda harus membuat 3 sedikit modifikasi pada file kode sumber cipher.c. Kemudian kompilasi ulang kode 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:

Juga, nonesandi harus ditambahkan ke/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

Tautan di bawah ini akan membantu Anda mendapatkan sumber ssh untuk sistem Debian dan Ubuntu:

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

Penghargaan untuk Dean Gaudet karena luar biasa

Menurut posting blog ini sangat bagus

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

Saya sarankan untuk mengatur cipher berikut. Pastikan juga kompresi dimatikan jika Anda menginginkan kinerja terbaik pada LAN. Harap perhatikan ini kemungkinan risiko keamanan, gunakan hanya pada LAN yang aman (misalnya di rumah, dll).

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

Ubah baris pertama untuk mencantumkan IP Anda sendiri di LAN Anda. Anda juga dapat memberikan nama host (dipisahkan oleh spasi). Ini memberi Anda kinerja scp terbaik di LAN.

JIKA Anda ingin mencoba terowongan yang sepenuhnya tidak terenkripsi dan tidak terkompresi Anda bisa mencoba menggunakan sesuatu seperti rinetduntuk meneruskan data, bukan SSH. Ini akan menerangi tambahan SSH sambil tetap menawarkan terowongan biner-aman untuk koneksi TCP.

Ketika Anda mengatakan bahwa Anda memiliki koneksi cepat di rumah, apakah Anda yakin bahwa itu cepat di kedua arah? Banyak koneksi rumah sangat asimetris (ADSL rumah saya misalnya ~ 11Mit hilir dan ~ 1,5Mbit hulu dan banyak yang lebih buruk dari itu, beberapa saya dapat mengutip dari koneksi teman / keluarga: 7M / 0,4M, 19M / 1,3M, 20M / 0,75 juta, ...). Ingatlah bahwa jika Anda menggunakan rumah sebagai proxy, data harus melalui tautan Anda dengan dua cara sehingga akan bergerak paling baikpada kecepatan hilir dan hulu Anda yang paling lambat dan Anda memiliki sedikit latensi tambahan untuk ikut berperan. ISP Anda mungkin juga dengan sengaja membatasi komunikasi hulu (baik selimut, atau secara selektif sehingga hal-hal seperti email dan situs web populer yang dipilih tidak terpengaruh) sebagai cara untuk mencegah orang yang menjalankan server / proksi dari tautan rumah mereka, meskipun ini relatif jarang.

Saya baru saja melakukan pengujian ekstensif tentang ini, dan cipher suite yang menghasilkan throughput tertinggi adalah aes-128-ctr dengan umac64 MAC. Pada mesin 4-core 3.4GHz saya melihat hampir 900MBytes / detik melalui localhost (untuk menghilangkan hambatan jaringan demi pembandingan)

Jika Anda benar-benar membutuhkan kinerja sebanyak itu, Anda menginginkan SSH terbaru, dan mungkin tambalan HPN-SSH .

Ini adalah opsi SSH satu sisi klien yang saya gunakan untuk koneksi SSH ke perangkat kelas bawah:

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

Tidak ada sandi yang didukung secara native di versi OpenSSH terbaru. Namun, sejak 7.6, OpenSSH menghapus dukungan SSHv1 dan memberi label "tidak ada" cipher untuk penggunaan internal.

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

Maka Anda perlu menambal dan mengkompilasi ulang untuk sisi server dan klien.

#define CFLAG_INTERNAL      0