Bagaimana saya bisa menonaktifkan enkripsi pada openssh?


21

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.


2
Sayang sekali patch rot13 ( miranda.org/~jkominek/rot13 ) tidak pernah tertangkap ...
Kenster

5
Saya sangat ragu bahwa enkripsi yang digunakan oleh SSH adalah penyebab koneksi Anda lambat selama server SSH Anda tidak berjalan pada jam tangan digital dari tahun 1980.
joschi

Jawaban:


17

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,umac-64@openssh.com,
      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.


3
Jika instalasi OpenSSH Anda (di kedua ujungnya) dipenuhi dengan dukungan untuk kode "tidak ada", Anda juga dapat menentukan itu, tetapi itu mengalahkan seluruh tujuan shell aman .
voretaq7

1
Untuk C-condong di antara kita, Anda dapat menambahkan {"none", SSH_CIPHER_NONE, 8, 0, 0, EVP_enc_null} ke cipher.c di dalam array cipher.
ŹV -

3
Saya juga bisa menunjukkan, Anda dapat menggunakan sesuatu seperti socat ( dest-unreach.org/socat ) untuk melakukan hal yang sama DAN menghindari semua overhead protokol SSH.
ŹV -

Saya pikir umac-64 adalah yang tercepat dari algoritma mac tersebut.
James Reinstate Monica Polk

Bagaimanapun, 96 bit MD5 sangat cepat.
ŹV -

7

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.


+1 untuk ini ... masalah yang sangat tidak mungkin adalah enkripsi dan kemungkinan besar akan menjadi koneksi ke host Anda di rumah.
DaveG

16
Saya berharap orang-orang akan berhenti mengatakan bahwa Anda tidak perlu melakukan ini dan masuk ke diskusi panjang tentang manfaat dan kejatuhan overhead enkripsi (jika atau jika tidak ada), dan coba saja dan jawab pertanyaannya. Saya tidak melihat alasan untuk menambahkan enkripsi berlebihan untuk tugas lokal saya di mesin lokal saya yang paling tidak saya butuhkan otentikasi, tetapi bekerja dari localhost ke localhost benar-benar tidak memerlukan enkripsi.
Marius

5
Tidak benar, cobalah untuk menyalin file besar menggunakan scp pada gig-ethernet. Intel iCore 5 memuat 80%.
lzap

@Izap> Ada lebih dari sekadar enkripsi sekalipun. Mentransfer file besar menggunakan ftp(tanpa ssl) juga memberi saya beban cpu 20 hingga 40%. Saya menyalahkan gig-ethernet murah yang membutuhkan terlalu banyak perhatian dari cpu.
spektra

Ketika Anda menggunakan SSH untuk mengirim / menerima ZFS, CPU mengalami hambatan;)
Xdg

6

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

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


hasil tanpa kata sandi 'tidak ada' tidak lengkap untuk topik ini. Saya punya banyak pogoplugv4 (800Mhz versi lengan = lambat) dan mereka sering mematok cpu dengan ssh. Inilah sebabnya mengapa orang mencari tidak ada sandi. ssh / sshd penggunaan CPU pada 100% berarti ini bukan masalah jaringan! saya harap saya ingat untuk kembali dan memposting cipher = tidak ada hasil ...
user2420786

Apakah Anda memiliki skrip yang Anda gunakan untuk menghasilkan data ini? Saya akan sangat tertarik dengan kinerja cipher saat ini ( chacha20-poly1305@openssh.com) pada perangkat keras saat ini.
Jakuje


3

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,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr,none

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

Penghargaan untuk Dean Gaudet karena luar biasa


2

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.


1

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.


ssh adalah standar pada kebanyakan mesin. rinetd tidak pada beberapa, tetapi terima kasih atas sarannya.
Marius

maka Anda harus mencoba netcat / nc
ThorstenS

0

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 .


0

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

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

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
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.