почему мой ssh-вход медленный?

<p>я вижу задержки в ssh logins. в частности, есть 2 места, где я вижу диапазон от мгновенных задержек до нескольких секунд.</p><ol> <li>между вводом команды ssh и получением запроса на вход в систему и</li> <li>между вводом ключевой фразы и загрузкой shell</li> </ol><p>теперь конкретно я смотрю на детали ssh только здесь. очевидно, что задержка в сети, скорость оборудования и операционных систем, сложные сценарии входа и т.д. могут вызвать задержки. для контекста я использую огромное количество дистрибутивов linux и некоторых хостов solaris, использующих в основном ubuntu, centos и macos x в качестве моих клиентских систем. практически все время конфигурация сервера ssh не отличается от настроек по умолчанию ос.</p><p>какие конфигурации сервера ssh мне могут быть интересны? есть ли параметры ос/ядра, которые можно настроить? трюки с логином? так далее?</p>

<p>попробуйте установить <code>usedns</code> в <code>no</code> в <code>/etc/sshd\_config</code> или <code>/etc/ssh/sshd\_config</code>.</p>

<p>когда я запустил <code>ssh -vvv</code> на сервере с аналогичной низкой производительностью, я увидел зависание:</p><pre><code>debug1: next authentication method: gssapi-with-mic </code></pre><p>отредактировав <code>/etc/ssh/ssh\_config</code> и закомментировав этот метод аутентификации, я восстановил производительность при входе в систему. вот что у меня есть в моем <code>/etc/ssh/ssh\_config</code> на сервере:</p><pre><code>gssapiauthentication no </code></pre><p>вы можете установить это глобально на сервере, чтобы он не принимал gssapi для аутентификации. просто добавьте <code>gssapiauthentication no</code> к <code>/etc/ssh/sshd\_config</code> на сервере и перезапустите службу.</p>

<p>для меня виновником было разрешение ipv6, истекло время ожидания. (думаю, неправильная настройка dns у моего хост-провайдера.) я обнаружил это, выполнив <code>ssh -v</code>, который показал, какой шаг завис.</p><p>решение заключается в <code>ssh</code> с опцией <code>-4</code>:</p><p><code>ssh -4 me@myserver.com</code></p>

<p>при использовании systemd вход в систему может зависать при обмене данными по протоколу dbus с logind после некоторых обновлений, после чего вам необходимо перезапустить logind</p><pre><code>systemctl restart systemd-logind </code></pre><p>видел, что на debian 8, arch linx, и в списке suse</p>

<p>вы всегда можете запустить <code>ssh</code> с параметром <code>-v</code>, который показывает, что делается в данный момент.</p><pre><code>$ ssh -v you@host с предоставленной вами информацией я могу предложить только некоторые конфигурации на стороне клиента:  поскольку вы пишете, что вводите пароли вручную, я бы посоветовал вам использовать аутентификацию с открытым ключом, если это возможно. это устраняет вас как узкое место скорости.   вы также можете отключить x-forwarding с помощью -x и аутентификацию с помощью -a (по умолчанию они уже могут быть отключены). особенно отключение x-forwarding может дать вам значительное улучшение скорости, если вашему клиенту нужно запустить x-сервер для команды ssh (например, в os x).  все остальное действительно зависит от того, с какими задержками вы сталкиваетесь, где и когда.

что касается пункта 2., здесь приведен ответ, который не требует модификации сервера и не требует наличия привилегий root/admin.вам нужно отредактировать ваш файл "user ssh_config":vi $home/.ssh/config </code></pre><p>(примечание: вам придется создать каталог $ home/.ssh, если он не существует)и добавить:host  gssapiauthentication no gssapidelegatecredentials yes вы можете сделать это для каждого хоста, если требуется :) пример:host linux-srv hostname 192.158.1.1 gssapiauthentication no gssapidelegatecredentials yes убедитесь, что ip-адрес соответствует ip вашего сервера. одним из замечательных преимуществ является то, что теперь ssh обеспечит автозаполнение для этого сервера. таким образом, вы можете ввести ssh lin + tab, и он должен автоматически заполниться до ssh linux-srv.

проверьте /etc/resolv.conf на сервере, чтобы убедиться, что dns-сервер, указанный в этом файле, работает нормально, и удалите все нерабочие dns.иногда это очень полезно.

помимо уже упомянутых проблем с dns, если вы подключаетесь к серверу с множеством подключений nfs, то может возникнуть задержка между паролем и запросом, так как команда quota проверяет ваше использование/квоту на всех файловых системах, не смонтированных с noquota , в системах solaris вы можете увидеть это в стандартном /etc/profile и пропустить его, запустив touch $home/.hushlogin</code>.</p>

<p>это, вероятно, относится только к debian/ubuntu openssh, который включает в себя user-group-modes.patch, написанный одним из сопровождающих пакетов debian. этот патч позволяет файлам ~/.ssh установить бит записи группы (g + w), если есть только один пользователь с таким же значением gid, что и у файла. функция patch\_permissions () патча выполняет эту проверку. один из этапов проверки состоит в том, чтобы просмотреть каждую запись passwd с помощью getpwent () и сравнить gid записи с gid файла.</p><p>в системе с большим количеством записей и/или медленной аутентификацией nis/ldap эта проверка будет медленной. nscd не кэширует вызовы getpwent (), поэтому каждая запись passwd будет считываться по сети, если сервер не является локальным. в системе, которую я обнаружил, добавлялось около 4 секунд для каждого вызова ssh или входа в систему.</p><p>исправление состоит в том, чтобы удалить бит записи для всех файлов в ~/.ssh, выполнив <code>chmod g-w ~/.ssh/*</code>.</p>

<p>я обнаружил, что перезапуск systemd-logind.service вылечил проблему только на несколько часов. изменение usepam с yes на no в sshd\_config привело к быстрому входу в систему, хотя motd больше не отображается. комментарии о проблемах безопасности?</p>

<p>этот поток уже предоставляет кучу решений, но мой здесь не приводится =). так и здесь. моя проблема (заняло около 1 минуты для входа по ssh в мой raspberry pi) была связана с повреждением файла .bash\_history. поскольку файл читается при входе в систему, это вызывало задержку входа в систему. как только я удалил файл, время входа в систему вернулось к нормальному, как мгновенное.</p><p>надеюсь, что это поможет другим людям.</p><p>ура</p>

<p>недавно я обнаружил другую причину медленного входа в систему через ssh.</p><p>даже если у вас есть <code>usedns no</code> в <code>/etc/sshd\_config</code>, sshd может выполнить обратный поиск dns, если <code>/etc/hosts.deny</code> имеет такую запись:</p><pre><code>nnn-nnn-nnn-nnn.rev.some.domain.com </code></pre><p>это может произойти, если в вашей системе установлен <a href="http://denyhosts.sourceforge.net/">denyhosts</a> .</p><p>было бы замечательно, если бы кто-то знал, как заставить denyhosts избегать помещения такого рода записи в <code>/etc/hosts.deny</code>.</p><p>вот ссылка на <a href="http://denyhosts.sourceforge.net/faq.html">denyhosts faq</a> , как удалить записи из <code>/etc/hosts.deny</code> - см. <a href="http://denyhosts.sourceforge.net/faq.html#3\_19">как удалить ip-адрес, заблокированный denyhosts?</a> </p>

<p>мы можем обнаружить, что предпочтительным методом разрешения имен является не файл хоста, а затем dns.</p><p>например, это будет обычная конфигурация:</p><pre><code>[root@linux1 ~]# cat /etc/nsswitch.conf|grep hosts #hosts: db files nisplus nis dns hosts: files dns myhostname </code></pre><p>сначала достигается файл hosts (опция: файлы), а затем dns (опция: dns), однако мы можем обнаружить, что была добавлена другая система разрешения имен, которая не работает и вызывает медлительность попыток выполнить обратное разрешение.</p><p>если порядок разрешения имен неправильный, вы можете изменить его по адресу: <code>/etc/nsswitch.conf</code></p><p>извлечено из: <a href="http://www.sysadmit.com/2017/07/linux-ssh-login-lento.html">http://www.sysadmit.com/2017/07/linux-ssh-login-lento.html</a> </p>

<p>чтобы завершить все ответы, показывающие, что разрешения dns могут замедлить вашу регистрацию ssh, иногда правила брандмауэра отсутствуют. например, если вы удалите все пакеты ввода по умолчанию</p><pre><code>iptables -t filter -p input drop </code></pre><p>тогда вам придется принять input для ssh-порта и dns-запроса</p><pre><code>iptables -t filter -a input -p tcp --dport 53 -j accept iptables -t filter -a input -p udp --dport 53 -j accept </code></pre>

<p>я перепробовал все ответы, но ни один из них не сработал. наконец я выясняю свою проблему:</p><p>сначала я запускаю <code>sudo tail -f /var/log/auth.log</code>, чтобы увидеть журнал ssh, затем в другом сеансе запускаю <code>ssh 172.16.111.166</code> и заметил ожидание</p><pre><code>/usr/bin/sss\_ssh\_knownhostsproxy -p 22 172.16.111.166 </code></pre><p>после поиска я нашел эту строку в/etc/ssd/ssh\_config</p><pre><code>proxycommand /usr/bin/sss\_ssh\_knownhostsproxy -p %p %h </code></pre><p>я прокомментировал это, и задержка прошла</p>

<p>отлично работает.</p><pre><code># uname -a sunos oi-san-01 5.11 oi\_151a3 i86pc i386 i86pc solaris # ssh -v sun\_ssh\_1.5, ssh protocols 1.5/2.0, openssl 0x009080ff # echo "gssapiauthentication no" >> /etc/ssh/sshd\_config # echo "lookupclienthostnames no" >> /etc/ssh/sshd\_config # svcadm restart ssh </code></pre><p>использовать dns нет не работать с openindiana !!!</p><p>прочитайте "man sshd\_config" для всех вариантов</p><p>«lookupclienthostnames no», если ваш сервер не может разрешить</p>

<p>если ни один из приведенных выше ответов не работает и вы сталкиваетесь с проблемами обратного просмотра dns, вы также можете проверить, установлен ли и работает ли <code>nscd</code> (демон кэширования службы имен).</p><p>если это проблема, то это потому, что у вас нет dns-кеша, и каждый раз, когда вы запрашиваете имя хоста, которого нет в вашем хост-файле, вы отправляете вопрос на ваш сервер имен вместо того, чтобы искать в своем кеше</p><p>я перепробовал все вышеперечисленные варианты, и единственное сработавшее изменение - это запуск <code>nscd</code>.</p><p>вы также должны проверить порядок разрешения dns-запросов в <code>/etc/nsswitch.conf</code>, чтобы сначала использовать файл hosts.</p>

<p>соединение <code>ssh -vvv</code> прошло нормально, пока оно не зависало в системе, пытаясь получить терминал в течение по крайней мере 20 секунд:</p><pre><code>debug1: channel 0: new [client-session] debug3: ssh\_session2\_open: channel\_new: 0 debug2: channel 0: send open debug1: requesting no-more-sessions@openssh.com debug1: entering interactive session. ... waiting ... waiting ... waiting </code></pre><p>после выполнения <code>systemctl restart systemd-logind</code><strong> на сервере </strong>у меня снова было мгновенное соединение!</p><p>это было на<strong> debian8 </strong>! так что проблема была в systemd!</p><p><strong> примечание: </strong><em>бастиен дурел уже дал ответ на этот вопрос, однако в нем отсутствует отладочная информация. надеюсь, это кому-нибудь пригодится.</em></p>

<p>примечание: это началось как учебное пособие «как отлаживать», но в итоге оказалось решением, которое помогло мне на сервере<strong> ubuntu </strong>16.04 lts.</p><p><strong>tldr</strong>: запустите <code>landscape-sysinfo</code> и проверьте, много ли времени уходит на выполнение этой команды; это распечатка информации о системе при новом входе в систему по ssh. обратите внимание, что эта команда доступна не во всех системах, пакет <code>landscape-common</code> устанавливает ее. («но подождите, есть еще ...»)</p><hr><p>запустите второй ssh-сервер на другом порту на машине, на которой возникла проблема, сделайте это в режиме отладки, который не заставит его работать и выведет отладочные сообщения:</p><pre><code>sudo /usr/sbin/sshd -ddd -p 44321 </code></pre><p>подключиться к этому серверу с другого компьютера в подробном режиме:</p><pre><code>ssh -vvv -p 44321 username@server </code></pre><p>мой клиент выводит следующие строки прямо перед началом сна:</p><pre><code>debug1: entering interactive session. debug1: pledge: network </code></pre><p>поиск в google не очень полезен, но журналы сервера лучше:</p><pre><code>debug3: mm\_send\_keystate: finished sending state [preauth] debug1: monitor\_read\_log: child log fd closed debug1: pam: establishing credentials debug3: pam: opening session ---- pauses here ---- debug3: pam: sshpam\_store\_conv called with 1 messages user child is on pid 28051 </code></pre><p>я заметил, что когда я изменяю <code>usepam yes</code> на <code>usepam no</code>, эта проблема решается.</p><p>не относится к <code>usedns</code> или любому другому параметру, только <code>usepam</code> влияет на эту проблему в моей системе.</p><p>я понятия не имею, почему, и я также не оставляю <code>usepam</code> в <code>no</code>, потому что я не знаю, каковы побочные эффекты, но это позволяет мне продолжить расследование.</p><p>поэтому, пожалуйста, не рассматривайте это как ответ, а как первый шаг, чтобы начать выяснять, в чем дело.</p><hr><p>поэтому я продолжил расследование и запустил <code>sshd</code> с <code>strace</code> (<code>sudo strace /usr/sbin/sshd -ddd -p 44321</code>). это привело к следующему:</p><pre><code>sendto(4, "<87>nov 20 20:35:21 sshd[2234]: "..., 110, msg\_nosignal, null, 0) = 110 close(5) = 0 stat("/etc/update-motd.d", {st\_mode=s\_ifdir|0755, st\_size=4096, ...}) = 0 umask(022) = 02 rt\_sigaction(sigint, {sig\_ign, [], sa\_restorer, 0x7f15dce784b0}, {sig\_dfl, [], 0}, 8) = 0 rt\_sigaction(sigquit, {sig\_ign, [], sa\_restorer, 0x7f15dce784b0}, {sig\_dfl, [], 0}, 8) = 0 rt\_sigprocmask(sig\_block, [chld], [], 8) = 0 clone(child\_stack=0, flags=clone\_parent\_settid|sigchld, parent\_tidptr=0x7ffde6152d2c) = 2385 wait4(2385, # blocks right here, before the rest is printed out # [{wifexited(s) && wexitstatus(s) == 0}], 0, null) = 2385 </code></pre><p>строка <code>/etc/update-motd.d</code> вызвала у меня подозрения, по-видимому, процесс ожидает результата, который находится в <code>/etc/update-motd.d</code></p><p>поэтому я <code>cd</code> 'в <code>/etc/update-motd.d</code> и запустил <code>sudo chmod -x *</code>, чтобы запретить pam запускать все файлы, которые генерируют этот динамический <code>message of the day</code>, который включает в себя загрузку системы и необходимость обновления пакетов, и это решило проблему.</p><p>это сервер, основанный на «энергосберегающем» процессоре n3150, который имеет много работы 24/7, поэтому я думаю, что собирать все эти motd-данные было слишком много для него.</p><p>я могу начать выборочно включать сценарии в этой папке, чтобы увидеть, какие из них менее вредны, но специальный вызов <code>landscape-sysinfo</code> очень медленный, и <code>50-landscape-sysinfo</code> вызывает эту команду. я думаю, что именно это вызывает наибольшую задержку.</p><p>после повторного включения большинства файлов я пришел к выводу, что причиной моих проблем были <code>50-landscape-sysinfo</code> и <code>99-esm</code>. для выполнения <code>50-landscape-sysinfo</code> потребовалось около 5 секунд, а для <code>99-esm</code> - около 3 секунд. все остальные файлы около 2 секунд в целом.</p><p>ни <code>50-landscape-sysinfo</code>, ни <code>99-esm</code> не имеют решающего значения. <code>50-landscape-sysinfo</code> печатает интересные системные статистические данные (а также если у вас мало места!), а <code>99-esm</code> печатает сообщения, связанные с <code>ubuntu extended security maintenance</code></p><p>наконец, вы можете создать скрипт с помощью <code>echo '/usr/bin/landscape-sysinfo' > info.sh && chmod +x info.sh</code> и получить эту распечатку по запросу.</p>

<p>мне нужен был gssapi, и я не хотел отключать обратный поиск dns. это просто не показалось хорошей идеей, поэтому я заглянул на главную страницу для resolv.conf. оказывается, что межсетевой экран между мной и серверами, с которыми я работал по ssh, мешал dns-запросам, потому что они были не в той форме, которую ожидал межсетевой экран. в конце концов, все, что мне нужно было сделать, это добавить эту строку в resolv.conf на серверах, с которыми я работал в ssh:</p><p><code>options single-request-reopen</code></p>

<p>примечательно, что обновление пакета bind в centos 7 сломалось по имени, теперь в журнале указано, что /etc/named.conf имеет проблему с разрешениями. он работал хорошо в течение нескольких месяцев с 0640. теперь он хочет 0644. это имеет смысл, так как именованный демон принадлежит «именованному» пользователю.<br> <br> с отключенным поименованием все было медленно, начиная с входа в систему по протоколу ssh и заканчивая обслуживанием страниц с локального веб-сервера, вялыми приложениями lamp и т.д., скорее всего потому, что каждый запрос на тайм-локальном сервере истекает, а затем выполняется поиск внешнего, вторичного dns, который настроен.</p>

<p>для меня была проблема в моем локальном файле <code>/etc/hosts</code>. таким образом, <code>ssh</code> пробовал два разных ip (один неверный), который длился вечно.</p><p>использование <code>ssh -v</code> помогло:</p><pre><code>$ ssh -vvv remotesrv openssh\_6.7p1 debian-5, openssl 1.0.1k 8 jan 2015 debug1: reading configuration data /home/mathieu/.ssh/config debug1: /home/mathieu/.ssh/config line 60: applying options for remotesrv debug1: reading configuration data /etc/ssh/ssh\_config debug1: /etc/ssh/ssh\_config line 19: applying options for * debug2: ssh\_connect: needpriv 0 debug1: connecting to remotesrv [192.168.0.10] port 22. debug1: connect to address 192.168.0.10 port 22: connection timed out debug1: connecting to remotesrv [192.168.0.26] port 22. debug1: connection established. </code></pre>