Почему мой SSH-вход медленный?

Я вижу задержки в SSH Logins. В частности, есть 2 места, где я вижу диапазон от мгновенных задержек до нескольких секунд.

1. Между вводом команды ssh и получением приглашения на вход в систему и
2. между вводом ключевой фразы и загрузкой оболочки

Теперь конкретно я смотрю на детали SSH только здесь. Очевидно, что задержка в сети, скорость оборудования и операционных систем, сложные сценарии входа и т. Д. Могут вызвать задержки. Для контекста я использую огромное количество дистрибутивов Linux и некоторых хостов Solaris, использующих в основном Ubuntu, CentOS и MacOS X в качестве моих клиентских систем. Практически все время конфигурация сервера ssh не отличается от настроек по умолчанию ОС.

Какие конфигурации сервера SSH мне могут быть интересны? Есть ли параметры ОС / ядра, которые можно настроить? Трюки с логином? И т.д?

Попробуйте установить UseDNSна noв /etc/sshd_configили /etc/ssh/sshd_config.

Когда я работал ssh -vvvна сервере с аналогичной низкой производительностью, я увидел зависание:

debug1: Next authentication method: gssapi-with-mic

Отредактировав /etc/ssh/ssh_configи закомментировав этот метод аутентификации, я восстановил производительность при входе в систему. Вот что у меня /etc/ssh/ssh_configна сервере:

GSSAPIAuthentication no

Вы можете установить это глобально на сервере, чтобы он не принимал GSSAPI для аутентификации. Просто добавьте GSSAPIAuthentication noк /etc/ssh/sshd_configна сервере и перезапустить службу.

Для меня виновником было разрешение IPv6, истекло время ожидания. (Плохая настройка DNS у моего хост-провайдера, наверное.) Я обнаружил это, выполнив ssh -v, что показало, какой шаг завис.

Решение заключается в том, чтобы sshс -4опцией:

ssh -4 me@myserver.com

При использовании systemd вход в систему может зависать при обмене данными по протоколу dbus с logind после некоторых обновлений, после чего вам необходимо перезапустить logind

systemctl restart systemd-logind

Видел, что на Debian 8, Arch Linx, и в списке suse

Вы всегда можете начать sshс -vопции, которая отображает, что делается в данный момент.

$ ssh -v you@host

С предоставленной вами информацией я могу предложить только некоторые конфигурации на стороне клиента:

• Поскольку вы пишете, что вводите пароли вручную, я бы посоветовал вам использовать аутентификацию с открытым ключом, если это возможно. Это устраняет вас как узкое место скорости.

• Вы также можете отключить переадресацию с помощью X и переадресацию с помощью -xаутентификации -a(по умолчанию они уже могут быть отключены). Особенно отключение X-forwarding может дать вам значительное улучшение скорости, если ваш клиент должен запустить X-сервер для sshкоманды (например, под OS X).

Все остальное действительно зависит от того, с какими задержками вы сталкиваетесь, где и когда.

Что касается пункта 2., здесь приведен ответ, который не требует модификации сервера и не требует наличия привилегий root / admin.

Вам нужно отредактировать ваш файл "user ssh_config":

vi $HOME/.ssh/config

(Примечание: вам придется создать каталог $ 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 .

Отлично работает

# 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

Использовать DNS нет не работать с OpenIndiana !!!

Прочитайте "man sshd_config" для всех вариантов

«LookupClientHostnames no», если ваш сервер не может разрешить

Если ни один из приведенных выше ответов не работает и вы сталкиваетесь с проблемами обратного просмотра DNS, вы также можете проверить, установлен ли nscd(и работает ли демон кэша службы имен).

Если это проблема, то это потому, что у вас нет DNS-кеша, и каждый раз, когда вы запрашиваете имя хоста, которого нет в вашем хост-файле, вы отправляете вопрос на ваш сервер имен вместо того, чтобы искать в своем кеше

Я перепробовал все вышеперечисленные варианты, и единственное, что сработало, это начало nscd.

Вы также должны проверить порядок разрешения DNS-запросов, /etc/nsswitch.confчтобы сначала использовать файл hosts.

Это, вероятно, относится только к Debian / Ubuntu OpenSSH, который включает в себя user-group-modes.patch, написанный одним из сопровождающих пакетов Debian. Этот патч позволяет файлам ~ / .ssh установить бит записи группы (g + w), если есть только один пользователь с таким же значением gid, что и у файла. Функция patch_permissions () патча выполняет эту проверку. Один из этапов проверки состоит в том, чтобы просмотреть каждую запись passwd с помощью getpwent () и сравнить gid записи с gid файла.

В системе с большим количеством записей и / или медленной аутентификацией NIS / LDAP эта проверка будет медленной. nscd не кэширует вызовы getpwent (), поэтому каждая запись passwd будет считываться по сети, если сервер не является локальным. В системе, которую я обнаружил, добавлялось около 4 секунд для каждого вызова ssh или входа в систему.

Исправление заключается в удалении доступного для записи бита для всех файлов в ~ / .ssh chmod g-w ~/.ssh/*.

Я обнаружил, что перезапуск systemd-logind.service вылечил проблему только на несколько часов. Изменение UsePAM с yes на no в sshd_config привело к быстрому входу в систему, хотя motd больше не отображается. Комментарии о проблемах безопасности?

Чтобы завершить все ответы, показывающие, что разрешения DNS могут замедлить вашу регистрацию ssh, иногда правила брандмауэра отсутствуют. Например, если вы УДАЛИТЕ все пакеты ввода по умолчанию

iptables -t filter -P INPUT DROP

тогда вам придется принять INPUT для SSH-порта и DNS-запроса

iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT

ssh -vvv Соединение прошло нормально, пока оно не зависло в системе, пытаясь получить терминал в течение по крайней мере 20 секунд:

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

После выполнения systemctl restart systemd-logind на сервере у меня снова было мгновенное соединение!

Это было на debian8 ! Так что проблема была в systemd!

Примечание: Бастьен Дурел уже дал ответ на этот вопрос, однако в нем отсутствует отладочная информация. Надеюсь, это кому-нибудь пригодится.

Недавно я обнаружил другую причину медленного входа в систему через ssh.

Даже если у вас есть UseDNS noв /etc/sshd_config, SSHD все еще может выполнить обратный поиск в DNS , если /etc/hosts.denyесть запись , как:

nnn-nnn-nnn-nnn.rev.some.domain.com

Это может произойти, если в вашей системе установлен DenyHosts .

Было бы замечательно, если бы кто-то знал, как заставить DenyHosts избегать такого входа /etc/hosts.deny.

Ниже приведена ссылка на часто задаваемые вопросы по DenyHosts о том, как удалить записи, /etc/hosts.denyсм. Раздел Как удалить IP-адрес, заблокированный DenyHosts?

Мы можем обнаружить, что предпочтительным методом разрешения имен является не файл хоста, а затем DNS.

Например, это будет обычная конфигурация:

[root@LINUX1 ~]# cat /etc/nsswitch.conf|grep hosts
#hosts:     db files nisplus nis dns
hosts:      files dns myhostname

Сначала достигается файл hosts (опция: файлы), а затем DNS (опция: dns), однако мы можем обнаружить, что была добавлена ​​другая система разрешения имен, которая не работает и вызывает медлительность попыток выполнить обратное разрешение.

Если порядок разрешения имен неправильный, вы можете изменить его по адресу: /etc/nsswitch.conf

Извлечено из: http://www.sysadmit.com/2017/07/linux-ssh-login-lento.html

Я перепробовал все ответы, но ни один из них не сработал. наконец я выясняю свою проблему:

сначала я запускаю, sudo tail -f /var/log/auth.log чтобы увидеть журнал SSH, а затем в другом сеансе запустить ssh 172.16.111.166и заметил, что ожидание на

/usr/bin/sss_ssh_knownhostsproxy -p 22 172.16.111.166

после поиска я нашел эту строку в / etc / ssd / ssh_config

ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h

Я прокомментировал это, и задержка прошла

Примечание: это началось как учебное пособие «Как отлаживать», но в итоге оказалось решением, которое помогло мне на сервере Ubuntu 16.04 LTS.

TLDR : запустите landscape-sysinfoи убедитесь, что выполнение этой команды занимает много времени; это распечатка информации о системе при новом входе в систему по SSH. Обратите внимание, что эта команда доступна не на всех системах, landscape-commonпакет устанавливает ее. («Но подождите, есть еще ...»)

Запустите второй ssh-сервер на другом порту на машине, на которой возникла проблема, сделайте это в режиме отладки, который не заставит его работать и выведет отладочные сообщения:

sudo /usr/sbin/sshd -ddd -p 44321

подключиться к этому серверу с другого компьютера в подробном режиме:

ssh -vvv -p 44321 username@server

Мой клиент выводит следующие строки прямо перед началом сна:

debug1: Entering interactive session.
debug1: pledge: network

Поиск в Google не очень полезен, но журналы сервера лучше:

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

Я заметил, что когда я перехожу UsePAM yesна UsePAM noто, эта проблема решена.

Не относится ни к UseDNSкаким другим настройкам, UsePAMвлияет только на эту проблему в моей системе.

Я понятия не имею , почему, и я также не выходя UsePAMна no, потому что я не знаю , какие побочные эффекты, но это позволяет мне продолжать расследование.

Поэтому, пожалуйста, не рассматривайте это как ответ, а как первый шаг, чтобы начать выяснять, в чем дело.

Поэтому я продолжил расследование и побежал sshdс strace( sudo strace /usr/sbin/sshd -ddd -p 44321). Это привело к следующему:

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

Строка /etc/update-motd.dзаставила меня заподозрить, по-видимому, процесс ждет результата от материала, который находится в/etc/update-motd.d

Поэтому я cdпопробовал /etc/update-motd.dи запустил sudo chmod -x *PAM, чтобы запретить PAM запускать все файлы, которые генерируют эту динамику Message Of The Day, включая загрузку системы и необходимость обновления пакетов, и это решило проблему.

Это сервер, основанный на «энергосберегающем» процессоре N3150, который имеет много работы 24/7, поэтому я думаю, что собирать все эти motd-данные было слишком много для него.

Я могу начать выборочно включать сценарии в этой папке, чтобы увидеть, какие из них менее вредны, но, в частности, вызов landscape-sysinfoочень медленный и 50-landscape-sysinfoвызывает эту команду. Я думаю, что именно это вызывает наибольшую задержку.

После повторного включения большинства файлов я пришел к выводу, что это 50-landscape-sysinfoи 99-esmстало причиной моих неприятностей. 50-landscape-sysinfoВыполнение заняло около 5 секунд и 99-esmоколо 3 секунд. Все остальные файлы около 2 секунд в целом.

Ни 50-landscape-sysinfoи 99-esmне являются решающими. 50-landscape-sysinfoраспечатывает интересную системную статистику (а также если у вас мало места!) и 99-esmпечатает сообщения, связанные сUbuntu Extended Security Maintenance

Наконец, вы можете создать скрипт echo '/usr/bin/landscape-sysinfo' > info.sh && chmod +x info.shи получить эту распечатку по запросу.

Этот поток уже предоставляет кучу решений, но мой здесь не приводится =). Так и здесь. Моя проблема (заняло около 1 минуты для входа по ssh в мой raspberry pi) была связана с повреждением файла .bash_history. Поскольку файл читается при входе в систему, это вызывало задержку входа в систему. Как только я удалил файл, время входа в систему вернулось к нормальному, как мгновенное.

Надеюсь, что это поможет другим людям.

Мне нужен был GSSAPI, и я не хотел отключать обратный поиск DNS. Это просто не показалось хорошей идеей, поэтому я заглянул на главную страницу для resolv.conf. Оказывается, что межсетевой экран между мной и серверами, с которыми я работал по SSH, мешал DNS-запросам, потому что они были не в той форме, которую ожидал межсетевой экран. В конце концов, все, что мне нужно было сделать, это добавить эту строку в resolv.conf на серверах, с которыми я работал в SSH:

options single-request-reopen​

Примечательно, что обновление пакета bind в CentOS 7 сломалось по имени, теперь в журнале указано, что /etc/named.conf имеет проблему с разрешениями. Он работал хорошо в течение нескольких месяцев с 0640. Теперь он хочет 0644. Это имеет смысл, так как именованный демон принадлежит «именованному» пользователю.

В случае с name down все было медленно, от входа в систему по протоколу ssh до обслуживания страниц с локального веб-сервера, вялых приложений LAMP и т. Д., Наиболее вероятно, потому что каждый запрос будет зависать на мертвом локальном сервере, прежде чем искать настроенный внешний вторичный DNS.

Для меня была проблема в моем локальном /etc/hostsфайле. Так что sshпробовал два разных IP (один неправильный), который длился вечно.

Использование ssh -vсделал трюк здесь:

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