что может вызвать медленную сессию ssh?

<p>я ssh на удаленном хосте, но производительность терминала плохая. символы, которые я печатаю, отображаются не сразу, а с некоторой задержкой. иногда два символа отображаются одновременно после задержки.</p>

<p>высокая задержка является еще одной причиной плохой производительности ssh. я настоятельно рекомендую использовать mtr в качестве лучшей замены для traceroute. он должен дать вам представление о том, где могут возникнуть проблемы с сетью.</p>

<p>отключение пересылки x11, если она вам не нужна (ssh -x) и включение сжатия (ssh -c) также может ускорить ваш сеанс.</p>

<p>я могу думать о двух возможных причинах:</p><ol> <li>потеря пакета при соединении</li> <li>высокая нагрузка на сервер.</li> </ol>

<p>используйте compression и compressionlevel of 9. это должно немного помочь. вы можете настроить эти параметры в/etc/ssh/ssh\_config. но если реальная сеть очень плохая, эти трюки не принесут много пользы.</p>

<p>я попытался измерить производительность сети, но вскоре обнаружил, что с терминалом все в порядке. что случилось?</p><p>у нас есть балансировка нагрузки между двумя интернет-каналами роутера. иногда он маршрутизирует мой ssh-трафик через wan1, а иногда через wan2. я предположил, что с одним каналом что-то не так. поэтому я измерил производительность сети с помощью mtr (отличный инструмент!) для двух каналов отдельно.</p><p>да! у wan2 21 прыжок за 110 мс, а у wan1 - 15 всего за 21 мс! проблема задержки в wan2.</p>

<p>наиболее очевидной причиной такого поведения является ссылка, которая либо насыщена, либо отбрасывает пакеты. сколько прыжков у вас есть от вашей рабочей станции до машины, на которой вы работаете? вы проанализировали трассировку, если применимо?</p>

<p>если вы используете openssh на длинном жировом канале (высокая пропускная способность + высокая задержка), убедитесь, что вы используете как минимум версию 4.7 с обеих сторон, поскольку она содержит исправления, заставляющие openssh использовать больший размер окна tcp.</p><pre><code> * the ssh channel window size has been increased, and both ssh(1) sshd(8) now send window updates more aggressively. these improves performance on high-bdp (bandwidth delay product) networks. </code></pre><p>это может быть важно, если вы хотите использовать соединение с его полным потенциалом, потому что в противном случае отправителю, возможно, придется ждать подтверждения, прежде чем он сможет продолжить отправку.</p>

<p>это может привести к неправильной настройке dns. после входа в систему сервер будет нормально реагировать и загружать и скачивать файлы довольно быстро, но ssh-вход будет медленным.</p>

<p>как уже говорили другие, это может произойти из-за задержки, потери в вашей сети, медленной работы сервера.<br> иногда вы видите 2 символа одного типа, потому что современный стек tcp использует алгоритм <a href="http://en.wikipedia.org/wiki/nagle's\_algorithm">naggle</a> .</p>

<p>это также может быть попытка грубой силы ssh, которая душит ваше соединение. каждый раз, когда моя сессия проходит медленно, я проверяю логи, и в большинстве случаев кто-то пытается сумасшедшим использовать пароли.</p>

<p>одна вещь, чтобы смотреть на это просто память сервера. я работал с ubuntu vm с 256 мб памяти и ssh был действительно вялым. удвоение до 512 мб решило проблему.</p>