У меня возникла проблема с настройкой, которую я использую для обслуживания нескольких клиентских серверов через удаленный SSH.
Следующая настройка:
1 сервер управления
X Произвольное количество серверов Заказчика, настроенных для подключения «служебной» учетной записи к моему управляющему серверу через SSH.
Я настроил клиентов для автоматического подключения к управляющему серверу с фиксированным IP-адресом через учетную запись службы с помощью autoSSH после загрузки. Это мое /etc/ssh/ssh_config на клиентской машине:
# Это общесистемный файл конфигурации клиента ssh. Видеть
# ssh_config(5) для получения дополнительной информации. Этот файл содержит значения по умолчанию для
# пользователей, а значения можно изменить в файлах конфигурации для каждого пользователя
# или в командной строке.
# Данные конфигурации анализируются следующим образом:
# 1. параметры командной строки
# 2. пользовательский файл
# 3. общесистемный файл
# Любое значение конфигурации изменяется только при первой установке.
# Таким образом, специфичные для хоста определения должны находиться в начале
# файл конфигурации и значения по умолчанию в конце.
# Общесайтовые значения по умолчанию для некоторых часто используемых опций. Для всеобъемлющего
# список доступных опций, их значения и значения по умолчанию см.
# справочная страница ssh_config(5).
Хозяин *
# ФорвардАгент нет
# ВпередX11 нет
# ForwardX11Trusted да
# Аутентификация по паролю да
# Аутентификация на основе хоста нет
# GSSAPIAАутентификация нет
# GSSAPIDelegateCredentials нет
# GSSAPIKeyExchange нет
# GSSAPITrustDNS нет
# Пакетный режим нет
# ПроверитьHostIP да
# AddressFamily любой
# ConnectTimeout 0
# Запрос StrictHostKeyChecking
# Идентификационный файл ~/.ssh/id_rsa
# Идентификационный файл ~/.ssh/id_dsa
# Идентификационный файл ~/.ssh/id_ecdsa
# Идентификационный файл ~/.ssh/id_ed25519
# Порт 22
# Протокол 2
# Шифры aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
# MAC hmac-md5,hmac-sha1,[email protected]
# EscapeChar ~
# Туннель нет
# TunnelDevice любое: любое
# PermitLocalCommand нет
# VisualHostKey нет
# ProxyCommand ssh -q -W %h:%p gateway.example.com
# RekeyLimit 1G 1h
SendEnv ЯЗЫК LC_*
HashKnownHosts да
GSSAPIAАутентификация да
Серверживеинтервал 300
На управляющем сервере я использую следующий sshd_config:
# $OpenBSD: sshd_config,v 1.103 09.04.2018 20:41:22 tj Exp $
# Это общесистемный файл конфигурации сервера sshd. Видеть
# sshd_config(5) для получения дополнительной информации.
# Этот sshd был скомпилирован с PATH=/usr/bin:/bin:/usr/sbin:/sbin
# Стратегия, используемая для опций в sshd_config по умолчанию, поставляемой с
# OpenSSH должен указать параметры со значением по умолчанию, где
# возможно, но оставьте их комментариями. Незакомментированные параметры переопределяют
# значение по умолчанию.
Порт --скрытый--
#AddressFamily любой
#ListenAddress 0.0.0.0
#ListenAddress ::
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key
# Шифры и ключи
#RekeyLimit по умолчанию нет
# Логирование
#SyslogFacility АУТЕНТИФИКАЦИЯ
#LogLevel ИНФОРМАЦИЯ
# Аутентификация:
#LoginGraceTime 2 м
#Строгиережимы да
#MaxAuthTries 6
#МаксСеансов 10
#PubkeyАутентификация да
# Ожидайте, что .ssh/authorized_keys2 в будущем будет игнорироваться по умолчанию.
#Файл авторизованных ключей .ssh/authorized_keys .ssh/authorized_keys2
#AuthorizedPrincipalsFile нет
#AuthorizedKeysCommand нет
#AuthorizedKeysCommandUser никто
# Для этого вам также понадобятся ключи хоста в /etc/ssh/ssh_known_hosts
#HostbasedAuthentication нет
# Измените на yes, если вы не доверяете ~/.ssh/known_hosts для
# Аутентификация на основе хоста
#IgnoreUserKnownHosts нет
# Не читать пользовательские файлы ~/.rhosts и ~/.shosts
#ИгнорироватьRhosts да
# Чтобы отключить туннелируемые пароли в открытом виде, измените здесь на no!
#PermitEmptyPasswords нет
# Измените на yes, чтобы включить пароли типа «запрос-ответ» (остерегайтесь проблем с
# некоторые модули и потоки PAM)
ВызовОтветАутентификация нет
# Опции Kerberos
#KerberosAuthentication нет
#KerberosOrLocalPasswd да
#KerberosTicketCleanup да
#KerberosGetAFSToken нет
# Параметры GSSAPI
#GSSAPIAНомер аутентификации
#GSSAPICleanupCredentials да
#GSSAPIStrictAcceptorПроверить да
#GSSAPIKeyExchangeнет
# Установите значение «да», чтобы включить аутентификацию PAM, обработку учетных записей,
# и обработка сеанса. Если этот параметр включен, аутентификация PAM будет
# быть разрешенным через ChallengeResponseAuthentication и
# Аутентификация PAM через ChallengeResponseAuthentication может обойти
# Если вы просто хотите, чтобы учетная запись PAM и проверка сеанса выполнялись без
# и ChallengeResponseAuthentication на «нет».
ИспользоватьPAM да
#AllowAgentForwarding да
AllowTcpForwarding да
Порты шлюза да
X11Переадресация да
#X11DisplayOffset 10
#X11UseLocalhost да
#PermitTTY да
Версия для печати
#PrintLastLog да
#TCPKeepAlive да
#PermitUserEnvironment нет
# Сжатие отложено
ClientAliveInterval 30
ClientAliveCountMax 99999
#UseDNS нет
#PidFile /var/run/sshd.pid
#Макс.Запусков 10:30:100
#PermitTunnel нет
#ChrootDirectory нет
#VersionAddendum нет
# нет пути к баннеру по умолчанию
#Баннер нет
# Разрешить клиенту передавать переменные среды локали
AcceptEnv ЯЗЫК LC_*
# переопределить значение по умолчанию отсутствия подсистем
Подсистема sftp /usr/lib/openssh/sftp-сервер
# Пример переопределения настроек для каждого пользователя
#Соответствие пользователю anoncvs
# X11Переадресация нет
# AllowTcpForwarding нет
# РазрешитьTTY нет
# cvs-сервер ForceCommand
ПарольАутентификация нет
Разрешить RootLogin да
В принципе, я ожидаю, что серверы просто будут держать соединения открытыми, поскольку обе стороны имеют достаточно тайм-аутов. Тем не менее, соединения случайным образом продолжают падать. я проверил /var/журнал/системный журнал и похоже sshd случайным образом сбрасывает одно из активных подключений при появлении нового подключения. Поэтому я почти уверен, что здесь я достиг некоторого предела подключения:
26 ноября 18:38:38 v2202102140578142103 systemd[1]: session-115234.scope: успешно.
26 ноября, 18:38:38 v2202102140578142103 systemd[1]: запущен сеанс 115376 пользовательской службы.
26 ноября 18:38:47 v2202102140578142103 systemd[1]: session-115235.scope: успешно.
26 ноября, 18:38:47 v2202102140578142103 systemd[1]: запущен сеанс 115377 пользовательской службы.
26 ноября 18:38:52 v2202102140578142103 systemd[1]: session-115236.scope: успешно.
26 ноября, 18:38:53 v2202102140578142103 systemd[1]: запущен сеанс 115378 пользовательской службы.
26 ноября 18:39:08 v2202102140578142103 systemd[1]: session-115237.scope: успешно.
26 ноября, 18:39:08 v2202102140578142103 systemd[1]: запущен сеанс 115379 пользовательской службы.
26 ноября 18:39:08 v2202102140578142103 systemd[1]: session-115238.scope: успешно.
26 ноября, 18:39:08 v2202102140578142103 systemd[1]: запущен сеанс 115380 пользовательской службы.
26 ноября 18:39:09 v2202102140578142103 systemd[1]: session-115239.scope: успешно.
26 ноября, 18:39:09 v2202102140578142103 systemd[1]: запущен сеанс 115381 пользовательской службы.
26 ноября 18:39:14 v2202102140578142103 systemd[1]: session-115240.scope: успешно.
26 ноября, 18:39:15 v2202102140578142103 systemd[1]: запущен сеанс 115382 пользовательской службы.
26 ноября 18:39:31 v2202102140578142103 systemd[1]: session-115241.scope: успешно.
26 ноября 18:39:31 v2202102140578142103 systemd[1]: session-115242.scope: успешно.
26 ноября, 18:39:31 v2202102140578142103 systemd[1]: запущен сеанс 115383 пользовательской службы.
26 ноября, 18:39:31 v2202102140578142103 systemd[1]: запущен сеанс 115384 пользовательской службы.
26 ноября 18:39:32 v2202102140578142103 systemd[1]: session-115243.scope: успешно.
26 ноября, 18:39:33 v2202102140578142103 systemd[1]: запущен сеанс 115385 пользовательской службы.
Вероятно, что-то очень просто исправить, но я не эксперт по сетям Linux, и я не смог найти ничего полезного в ходе собственных исследований. Итак, надеюсь, кто-то может указать мне предел, который я должен изменить, чтобы это поведение прекратилось?
Заранее спасибо!
