87

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

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

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

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

22 ответа22

115

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

36

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

16

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

Решением является ssh с опцией -4 :

ssh -4 me@myserver.com

12

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

systemctl restart systemd-logind

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

8

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

$ ssh -v you@host

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

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

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

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

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 .

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/* .

1

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

1

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

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

ура

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

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

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

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

UseDNS нет не работают с OpenIndiana !!!

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

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

1

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

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

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

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

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!

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

0

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

Так d cd I»в /etc/update-motd.d и побежал sudo chmod -x * для того , чтобы препятствовать 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 и получить эту распечатку по запросу.

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.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .