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

95

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

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

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

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

Питер Лайонс
источник
Вы используете локальные учетные записи? - Иногда я нахожу, что аутентификация PAM может добавить задержку для входа в систему с помощью SSH
Sirex
Обычно локальные аккаунты. Иногда шек.
Питер Лайонс

Ответы:

122

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

Пол Р
источник
7
+1, что является наиболее распространенной причиной задержки при входе в ssh
matthias krull
2
Примечание Solaris 11: я попытался использовать параметр UseDNS no на Solaris 11, и он повредил запуск службы. Не совсем дружеский ответ службы. «. - комментарий Кита Хоффмана
Сатьяджит Бхат
3
Я скептически относился к тому, что я использую для входа, используя IP-адрес (домашняя локальная сеть), но это решение решило мою проблему. Ради Google, хотя это происходило сразу после этого, задержка не имела ничего общего с сообщением «key: /home/mylogin/.ssh/id_ecdsa ((nil))» (при запуске ssh -vvv).
Скиппи ле Гран Гуру
2
+1 за то, что сделал это явным, файл /etc/ssh/sshd_config! Я добавлял /etc/sshd_configи не видел никакой разницы вообще !!
vyom
1
@SkippyleGrandGourou: В некоторых версиях Solaris использовался модифицированный OpenSSH, называемый SunSSH, который имел некоторую досадную несовместимость. Solaris 11.3 добавляет OpenSSH обратно и SunSSH будет в конечном итоге удален ...
Герт ван ден Берг
37

Когда я работал 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на сервере и перезапустить службу.

Джошуа
источник
Я обнаружил, что это происходит с моими серверами RHEL5 после настройки логинов winbind / ad.
Чад
Это работает для меня на сервере Ubuntu 14.04.
Penghe Geng
Для CentOS 7 нужно установить как GSSAPIAuthentication noи UseDNS noв /etc/ssh/sshd_configфайл.
Санри
19

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

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

ssh -4 me@myserver.com

Энтони
источник
2
Я подозреваю, что все больше и больше из нас увидят это с течением времени, и вещи (плохо и) медленно приспосабливаются к IPV6. Спасибо!
мудрец
1
... и этот ответ особенно бесполезен без отладочного сообщения, подтверждающего, что это проблема.
EP
По моему опыту, это очень распространенная проблема, когда SSH прослушивает интерфейсы с двумя стеками, и первое, что я проверяю, когда я могу войти в систему, но это занимает больше времени, чем ожидалось.
Mogget
Есть ли шанс, что мы сможем исправить IPv6, а не использовать IPv4 по умолчанию?
msrd0
Это, вероятно, причина, по которой UseDNS no answer работает. использование -vvv показывает только паузу debug2: resolving "thing.net.au" port 22без ошибок, но это не происходит с -4, указывая, что это проблема DNS IPv6.
вечера
16

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

systemctl restart systemd-logind

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

Бастьен Дурель
источник
1
Ого, теперь это был виновник! Огромное спасибо!
Махатманич
Мне то же. Сначала нужно было исключить все возможные проблемы с DNS и SSH. Примечание. Если проблема относится и к медленному sudo, попробуйте сначала.
Майкл
Я только что закончил некоторые обновления с RHEL6 до RHEL7 и заметил эту проблему. Этот ответ также исправил мою проблему.
user53029
Большое спасибо, это работает как шарм.
Bảo Nam
9

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

$ ssh -v you@host

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

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

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

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

Бенджамин Банье
источник
Хороший совет о многословии, вы также можете увеличить его, имея больше v. До 3 IIRC.
Вторник
7

Что касается пункта 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.

Гюйгенс
источник
4

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

Иногда это очень полезно.

Елена Тимошкина
источник
2

Помимо уже упомянутых проблем с DNS, если вы подключаетесь к серверу со многими монтированными NFS, то может возникнуть задержка между паролем и запросом, так как quotaкоманда проверяет ваше использование / квоту на всех файловых системах, не смонтированных с noquota. В системах Solaris вы можете увидеть это по умолчанию /etc/profileи пропустить его, запустив touch $HOME/.hushlogin .

alanc
источник
1

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

# 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», если ваш сервер не может разрешить

Гуго
источник
1

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

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

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

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

altmas5
источник
1

Это, вероятно, относится только к 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/*.

jamesy
источник
1

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

Крис Блейк
источник
Здесь я рассмотрел КАЖДЫЕ другие предложения, и это единственное, что устранило проблему на моем сервере включения Samba4 ... СПАСИБО!
Девен Филлипс
ВНИМАНИЕ: «UsePAM no» не поддерживается в Red Hat Enterprise Linux и может вызвать несколько проблем.
bbaassssiiee
1

Чтобы завершить все ответы, показывающие, что разрешения 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
RGuillome
источник
1

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!

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

mahatmanich
источник
У меня была та же проблема с «Входом в интерактивный сеанс», висящей на RHEL7 (CentOS 7), и я решил ее, комментируя session [default=1] pam_lastlog.so nowtmp showfailedв /etc/pam.d/postlogin. Видимо, обновление файла lastlog было невероятно медленным на моем VPS-сервере OpenVZ на основе контейнера.
Джастин
1

Недавно я обнаружил другую причину медленного входа в систему через 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?

Марсело Роберто Хименес
источник
1

Мы можем обнаружить, что предпочтительным методом разрешения имен является не файл хоста, а затем 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

Ханс Грубер
источник
1

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

сначала я запускаю, 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

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

HamedH
источник
1

Примечание: это началось как учебное пособие «Как отлаживать», но в итоге оказалось решением, которое помогло мне на сервере 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

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

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

user3320224
источник
0

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

options single-request-reopen

Сапан Гангули
источник
0

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

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

Дэвид Рамирес
источник
0

Для меня была проблема в моем локальном /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.
малат
источник
/etc/hostsСервера?
Даниэль Ф