Як я можу відключити шифрування на openssh?

У мене виникли проблеми з використанням комбінації openssh (сервер) та putty (client) для використання віддаленого webproxy. Я хотів би вимкнути шифрування і перевірити результати, щоб побачити, чи має це значення. Як я можу це зробити? Чи є щось, що я можу змінити в sshd_config. Я дуже новачок у відкритті.

Будь-які інші ідеї будуть вдячні.

В основному я встановив IE використовувати шкарпетки 127.0.0.1 як проксі. Я підключаю свою шпаклівку до свого відкритого сервера вдома і вуаля - я можу переглядати Інтернет через це. Однак це надзвичайно повільно, хоча я знаю, що у мене є швидкий зв’язок із домом (наприклад, ftp працює зі швидкістю 50 Кбайт / сек.

Без перекомпіляції нічого не можна зробити, наскільки я знаю. Однак ви можете перейти на ARC4 або Blowfish, які, безсумнівно, швидко працюють на сучасному обладнанні.

НАЙКРАЩА продуктивність (що стосується циклів годин), яку можна досягти, це додавання

compression no

Це можна зробити, змінивши

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

до

ciphers         arcfour,blowfish-cbc

Якщо ви хочете вичавити якісь додаткові показники, ризикуючи сумісністю, ви можете змінити

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

до

macs  hmac-md5-96

Якщо ви все ще вважаєте, що це занадто багато накладних витрат, ви можете повернутися до v1 або просто зробити стандартну VPN.

Якщо клієнт або сервер різко недосяжні, я б дуже сумнівався, що саме шифрування викликає ваші проблеми з продуктивністю. Я регулярно використовую проксі-проксі-шкарпетки "-D 8080", і ніколи нічого не помічав, крім дуже незначного уповільнення.

Одне, що потрібно перевірити, - це побачити, яка затримка знаходиться між вашим клієнтом та сервером. Якщо це дуже латентне з'єднання, ви, безперечно, побачите низьку продуктивність в тунелі під час використання HTTP, не спостерігаючи при цьому проблеми з продуктивністю FTP. Як тільки передача FTP відбувається, затримка насправді не має значення, але з HTTP ви маєте справу з веб-сторінками, які можуть мати 50 або більше окремих рукостискань HTTP, які повинні відбутися. Підключення з високою затримкою дійсно сповільнить цей процес і зробить перегляд нестерпним.

Тож як би там не було, рекомендації Зефіра Пеллеріна є надійними. Якщо ви дійсно думаєте, що саме шифрування викликає проблему з усіма силами, переключіться на інший шифр. Я б запропонував спочатку вивчити затримку, оскільки це, здається, є набагато більш імовірним кандидатом.

Цей потік змусив мене робити власні орієнтири, і я з'ясував, що продуктивність змінюється не лише різними шифрами / MAC, але це також має значення, які дані ви надсилаєте, які процесори задіяні та як налаштована мережа.

Отже, IMO, що потрібно зробити, це запустити власні тести та знайти найкращі настройки для вашої ситуації.

Якщо когось цікавить, ось результати моїх тестів, порівнюючи сервер, керований Intel E5506, і 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

Але, окрім "топ-10", повний результат можна знайти тут .

Мені вдалося скомпілювати sshd / ssh за допомогою шифру "none" за допомогою цієї публікації: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=24559#58

Це дуже стара публікація, але ви повинні внести 3 невеликі зміни у файл вихідного коду cipher.c. Потім перекомпілюйте код 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:

Також noneшифр потрібно буде додати до вашого/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

Посилання нижче допоможуть вам отримати джерело ssh для систем Debian та Ubuntu:

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

Подяка Діну Гауде за те, що він приголомшливий

Відповідно до цієї дуже приємної публікації в блозі

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

Рекомендую встановити наступні шифри. Також переконайтеся, що стиснення вимкнено, якщо ви хочете отримати найкращу ефективність в локальній мережі. Зверніть увагу, що це можливий ризик безпеки, використовуйте лише в захищеній локальній мережі (наприклад, в домашніх умовах тощо).

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

Змініть перший рядок, щоб перелічити власні IP-адреси у вашій локальній мережі. Ви також можете вказати імена хостів (розділені пробілом). Це дає найкращі результати роботи scp в локальній мережі.

Якщо ви хочете спробувати повністю незашифрований і нестиснений тунель, ви можете спробувати використовувати щось на кшталт rinetdпересилання даних замість SSH. Це скасує додатки SSH, хоча стиль пропонує простий бінарний безпечний тунель для TCP-з'єднань.

Коли ви говорите, що у вас швидкий зв’язок вдома, ви впевнені, що це швидко в обох напрямках? Багато домашніх з'єднань дуже асиметричні (наприклад, мій домашній ADSL - це ~ 11Mit низхідній та ~ 1,5 Мбіт вгору за течією, і багато гірше, ніж деякі, я можу процитувати з боку друзів / сімейних зв’язків: 7M / 0.4M, 19M / 1.3M, 20M / 0,75М, ...). Зауважте, що якщо ви використовуєте додому як проксі, дані повинні пройти по вашому посиланню обома способами, тому вони рухатимуться в кращому випадкуна найповільнішій швидкості за течією вгору і за течією, і у вас є шматок додаткової затримки, щоб також враховувати. Також ваш Інтернет-провайдер може навмисно перешкоджати комунікації вгору за течією (або ковдрою, або вибірково, щоб на такі речі, як електронна пошта та вибрані популярні веб-сайти не впливали) як спосіб відмовити людей, які працюють із серверами / проксі-серверами, від своїх домашніх посилань, хоча це порівняно рідко.

Я щойно робив обширні тести з цього приводу, і набір шифрів, що давав найбільшу пропускну здатність, був aes-128-ctr з umac64 MAC. На 4-ядерному апараті частотою 3,4 ГГц я бачив майже 900 Мбіт / с через localhost (щоб усунути вузькі місця в мережі заради тестування)

Якщо вам справді потрібна така велика продуктивність, ви хочете отримати найновіший SSH та, можливо, виправлення HPN-SSH .

Це один варіант SSH на стороні клієнта, який я використовував для підключення SSH до пристроїв низького класу:

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

Жоден шифр не підтримується в останніх версіях OpenSSH. Однак, починаючи з 7.6, OpenSSH видалив підтримку SSHv1 та позначив шифр "немає" для внутрішнього використання.

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

Тоді вам потрібно виправлення та перекомпіляція як для сервера, так і для клієнта.

#define CFLAG_INTERNAL      0