Чому вхід у SSH повільний?


95

Я спостерігаю затримки в реєстрації в SSH. Зокрема, є дві плями, де я бачу діапазон від миттєвої до багатосекундної затримки.

  1. Між видачею команди ssh та отриманням підказки для входу та
  2. між введенням парольної фрази і завантаженням оболонки

Зараз конкретно я дивлюся деталі ssh лише тут. Очевидно, що затримка в мережі, швидкість роботи обладнання та ОС, складні сценарії входу тощо можуть спричинити затримки. У контексті я переглядаю величезну кількість дистрибутивів Linux та деяких хостів Solaris, що використовують в основному Ubuntu, CentOS та MacOS X як мої клієнтські системи. Майже весь час конфігурація сервера ssh не змінюється в налаштуваннях ОС за замовчуванням.

Які конфігурації ssh-сервера мене повинні зацікавити? Чи є параметри ОС / ядра, які можна налаштувати? Фокуси входу в оболонку? Etc?


ви використовуєте локальні акаунти? - іноді я знаходжу автентифікацію пам’яті, можна додати затримку для входу в систему з ssh
Sirex

Зазвичай локальні рахунки. Іноді НІС.
Пітер Ліонс

Відповіді:


122

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


7
+1, що є найпоширенішою причиною затримки під час входу в ssh
matthias krull

2
"Примітка Solaris 11: Я намагався використовувати параметр UseDNS не на Solaris 11, і це пошкодило запуск сервісу. Не зовсім дружня відповідь сервісом. YMMV з іншими варіантами * Nix, але, здається, UseDNS ні може бути неприйнятним варіантом у Solaris 11 . " - коментар Кіта Хоффмана
Сатьядхіт Бхат

3
Я був скептично налаштований для входу за допомогою IP-адреси (домашня локальна мережа), але це рішення вирішило мою проблему. Заради Google, хоча це сталося одразу після цього, затримка не мала нічого спільного з повідомленням "key: /home/mylogin/.ssh/id_ecdsa ((nil))" (під час запуску ssh -vvv).
Skippy le Grand Gourou

2
+1, щоб зробити це явним, файл /etc/ssh/sshd_config! Я додавав /etc/sshd_configі не бачив різниці зовсім !!
vyom

1
@SkippyleGrandGourou: Деякі версії Solaris використовували модифікований OpenSSH під назвою SunSSH, який мав деякі набридливі несумісності. Solaris 11.3 додає OpenSSH назад, а SunSSH з часом буде видалено ...
Gert van den Berg

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, коли налаштовані входи / рекламні входи.
Чад

Це працює для мене на сервері 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 слухає інтерфейси з двома стеками, і перше, що я перевіряю, коли я можу ввійти, але це займає більше часу, ніж очікувалося.
Могет

Чи є якийсь шанс, що ми можемо виправити IPv6, а не дефолт до IPv4?
msrd0

Це, мабуть, причина, що відповідь UseDNS не працює. використовуючи -vvv лише показує, що вона робить паузу debug2: resolving "thing.net.au" port 22без помилок, але це не відбувається з -4, що означає, що це проблема DNS IPv6.
pmc

16

При systemd, реєстрація може зависати на dbus-зв’язку з logind після деяких оновлень, тоді вам потрібно перезапустити логін

systemctl restart systemd-logind

Побачила це на Debian 8, arch linx та у списку суз


1
Ох вау, тепер це був винуватець! Дякую купу!
махатманіч

Те саме для мене. Знадобився час, щоб спершу виключити всі можливі проблеми DNS та SSH. Примітка. Якщо проблема стосується також повільного судо, спробуйте це спочатку.
Майкл

Я щойно закінчив декілька оновлень на місці від RHEL6 до RHEL7 і помітив цю проблему. Ця відповідь також вирішила мою проблему.
user53029

велике спасибі, це працює як шарм.
Bảo Nam

9

Ви завжди можете почати sshз -vопції, яка відображає те, що робиться на даний момент.

$ ssh -v you@host

З наданої вами інформації я можу запропонувати лише деякі конфігурації на стороні клієнта:

  • Оскільки ви пишете, що вводите паролі вручну, я б запропонував вам використовувати аутентифікацію відкритих ключів, якщо це можливо. Це видаляє вас як вузьке вузьке місце.

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

Все інше насправді залежить від того, які затримки ви відчуваєте, де і коли.


Хороший натяк на багатослів’я, ви також можете збільшити його, маючи більше v. До 3 IIRC.
vtest

7

Щодо точки 2. Ось відповідь, яка не потребує модифікації сервера, а також не має права root / адміністратора.

Вам потрібно відредагувати файл "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

Робота чудово.

# 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 ні", якщо ваш сервер не може вирішити


1

Якщо жоден з вищезазначених відповідей не працює, і ви зіткнулися з проблемами зворотного пошуку dns, ви також можете перевірити, чи nscdвстановлений (запущений кеш служби служб імен) встановлений і працює.

Якщо це проблема, це тому, що у вас немає кеш-файлу dns, і кожного разу, коли ви запитуєте ім'я хоста, яке відсутнє у вашому файлі хоста, ви надсилаєте запитання на свій сервер імен, а не в кеш-пам'ять.

Я спробував усі вищеперелічені варіанти, і єдина зміна, яка працювала - це початок nscd.

Ви також повинні перевірити замовлення, щоб зробити дозвіл на запит dns, /etc/nsswitch.confщоб спочатку використовувати файл хостів.


1

Це, мабуть, характерно лише для Debian / Ubuntu OpenSSH, що включає користувальницьку групу-mode.patch, написану одним з обслуговуючих пакетів Debian. Цей патч дозволяє файлам ~ / .ssh встановити груповий біт для запису (g + w), якщо є лише один користувач з тим самим gid, як і файл. Функція secure_permissions () виправлення виконує цю перевірку. Однією з фаз перевірки є проходження кожного запису passwd за допомогою getpwent () та порівняння gid запису з gid файлу.

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

Виправлення полягає в тому, щоб видалити біт, який можна записати, з усіх файлів у ~ / .ssh chmod g-w ~/.ssh/*.


1

Я виявив, що перезапуск systemd-logind.service вилікував проблему лише за кілька годин. Зміна UsePAM з "так" на "ні" в sshd_config призвело до швидкого входу в систему, хоча motd більше не відображається. Коментарі щодо проблем безпеки?


Я пережив КОЖНУ іншу пропозицію тут, і це єдине, що вирішило проблему на моєму сервері включення Samba4 ... ДЯКУЮ!
Девен Філліпс

УВАГА: 'UsePAM no' не підтримується в Red Hat Enterprise Linux і може спричинити кілька проблем.
bbaassssiiee

1

Щоб виконати всі відповіді, які показують, що роздільна здатність DNS може уповільнити ваш sh логін, іноді правила брандмауера відсутні. Наприклад, якщо за замовчуванням ви скидаєте всі пакети INPUT

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

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 ! Тож системна проблема була тут!

Примітка: Бастієн Дюрель вже дав відповідь на це питання, однак у ньому відсутня інформація про налагодження. Я сподіваюся, що це комусь корисно.


У мене була та сама проблема з "Введенням в інтерактивну сесію", що висить на RHEL7 (CentOS 7), і я вирішив її, коментуючи session [default=1] pam_lastlog.so nowtmp showfailedв /etc/pam.d/postlogin. Очевидно, оновлення файлу останнього журналу було надзвичайно повільним у моєму контейнері OpenVZ VPS.
Джастін ᚅᚔᚈᚄᚒᚔ

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

Спочатку досягається файл хостів (опція: файли), а потім 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

Я прокоментував це і затримка пішла


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

Гуглінг, який насправді не корисний, але журнали сервера краще:

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«d в /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та отримати цю роздруківку за запитом.


1

Цей потік вже пропонує купу рішень, але мої тут не дано =). Так ось воно. Моя проблема (щоб увійти до мого малинового пі (пішло приблизно 1 хвилину), була пов’язана із пошкодженим файлом .bash_history. Оскільки файл читається під час входу, це спричинило затримку входу. Після того як я видалив файл, час входу повернувся до нормального рівня, як миттєвий.

Сподіваюся, що це допоможе деяким іншим людям.


0

Для мене мені знадобився GSSAPI, і я не хотів вимикати зворотні пошуки DNS. Це просто не здавалося гарною ідеєю, тому я перевірив головну сторінку для резолюції.conf. Виявляється, брандмауер між мною та серверами, яким я був SSHing, заважав запитам DNS, оскільки вони не були у формі, якої брандмауер очікував. Зрештою, все, що мені потрібно було, - це додати цей рядок до reslav.conf на серверах, на які я SSHing:

options single-request-reopenСігналы абмеркавання


0

Примітно, що оновлення пакета bind на CentOS 7 порушило ім'я, вказуючи в журналі, що в /etc/named.conf була проблема з дозволом. Він працював добре місяцями з 0640. Тепер він хоче 0644. Це має сенс, оскільки названий демон належить користувачеві "названого".

З ім'ям вниз все пройшло повільно, від входу в 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Сервера?
Даніель Ф
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.