it-swarm-ru.tech

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

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

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

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

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

89
Peter Lyons

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

116
Paul R

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

36
Joshua

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

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

ssh -4 [email protected]

17
Anthony

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

systemctl restart systemd-logind

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

13
Bastien Durel

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

$ ssh -v [email protected]

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

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

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

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

8
Benjamin Bannier

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

7
Huygens

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

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

4
Elena Timoshkina

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

2
alanc

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

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

1
Chris Blake

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

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

Ура

1
user3320224

Недавно я обнаружил другую причину медленного входа в систему через 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 FAQ , как удалить записи из /etc/hosts.deny - см. Как удалить IP-адрес, заблокированный DenyHosts?

1
Marcelo Roberto Jimenez

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

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

[[email protected] ~]# 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
Hans Gruber

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

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

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

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

# 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
Hugues

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

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

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

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

1
altmas5

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

debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
... waiting ... waiting ... waiting

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

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

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

1
mahatmanich

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

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


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

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

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

ssh -vvv -p 44321 [email protected]

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

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 запускать все файлы, которые генерируют этот динамический 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
Daniel F

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

options single-request-reopen

0
Sapan Ganguly

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

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

0
David Ramirez

Для меня была проблема в моем локальном файле /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.
0
malat