У меня проблемы с производительностью при использовании комбинации openssh (сервер) и putty (клиент) для использования удаленного веб-прокси. Я хотел бы отключить шифрование и проверить результаты, чтобы увидеть, имеет ли это значение. Как я могу это сделать? Есть ли что-нибудь, что я могу изменить в sshd_config. Я новичок в openssh.
Любые другие идеи будут оценены.
Я в основном настроил свой IE на использование 127.0.0.1 socks в качестве прокси. Я подключаю свою замазку к своему серверу openssh дома и вуаля - я могу просматривать Интернет через нее. Однако это невероятно медленно, хотя я знаю, что у меня быстрое соединение с моим домом (например, 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
Если вы все еще считаете, что это слишком много накладных расходов, вы можете вернуться к версии 1 или просто использовать стандартный VPN.
Я очень сомневаюсь, что, если только клиент или сервер не имеют крайне недостаточной мощности, именно шифрование вызывает проблемы с производительностью. Я регулярно использую прокси-сервер ssh socks "-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:
Благодарим Дина Годе за то, что он потрясающий
Согласно этому очень красивому сообщению в блоге
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, например, составляет ~ 11 Мбит нисходящего потока и ~ 1,5 Мбит восходящего потока, и многие из них хуже, некоторые из них я могу процитировать из друзей / родственников: 7 Мбит / с / 0,4 Мбит / с, 19 Мбит / с / 1,3 Мбит / с, 20 Мбит / с / 0,75M, ...). Помните, что если вы используете дом в качестве прокси, данные должны проходить по вашей ссылке в обоих направлениях, поэтому они будут перемещаться в лучшем случае на самой медленной из ваших нисходящих и восходящих скоростей, и у вас также есть дополнительная задержка, чтобы учесть ее. Кроме того, ваш интернет-провайдер может намеренно ограничивать восходящую коммуникацию (либо полностью, либо выборочно, чтобы не затрагивать такие вещи, как электронная почта и избранные популярные веб-сайты) в качестве способа отговорить людей, использующих серверы / прокси-серверы от своих домашних ссылок, хотя это относительно редко.
Я только что провел обширное тестирование, и набор шифров, который дал самую высокую пропускную способность, был aes-128-ctr с MAC umac64. На 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 и пометил шифр "none" для внутреннего использования.
#define CFLAG_NONE (1<<3)
#define CFLAG_INTERNAL CFLAG_NONE /* Don't use "none" for packets */
Затем вам потребуется установить исправления и перекомпилировать как на стороне сервера, так и на стороне клиента.
#define CFLAG_INTERNAL 0