ОБНОВЛЕНИЕ ВНИЗ ->
Я использую Red Hat Enterprise Linux Server версии 7.4 (Maipo) ВМ в моем классе OS около 20 студентов, которые обычно запускают около двух ssh-подключений к этой машине со своими собственными идентификаторами пользователей. Кажется, это нормально работает, когда ученики текут в класс.
Однако в начале урока, когда большинство студентов пытается войти в систему, у меня есть студенты, которые не могут войти в систему с “ssh: connect to host xxx.xxx.xxx.xxx port 22: Connection refused”
сообщение. Ожидание около 20 минут, кажется, в конечном итоге позволит войти еще нескольким людям. Sshd определенно работает. Набор пользователей, которым отказывают, варьируется, а иногда также включает меня. Я мог успешно подключиться через ssh за несколько минут до этого, но потом не могу начать вторую сессию.
Весь наш исходящий трафик использует настройку Many-to-1 NAT, поэтому все входящие ssh-соединения на сервере будут отображаться как поступающие с одного и того же IP-адреса. Посмотрев документы и немного покопавшись, я изменил следующие два параметра в sshd_config файл:
#MaxSessions 10
MaxSessions 500
и
#MaxStartups 10:30:100
MaxStartups 75:10:200
Как я понимаю MaxSessions определяет количество активных ssh-подключений к серверу - даже если они исходят только с одного IP-адреса, а MaxStartups относится к первоначальным попыткам подключения (например, людям, пытающимся войти в систему, которые еще не предоставили пароль), поэтому в этом случае я мог бы разместить 75 при запуске, а затем скорость увеличилась бы на 10%, пока не достигнет предела в 200 (так что я должен установить MaxSessions, и это число должно быть таким же?)
Я использую аутентификацию по паролю, а вход root отключен. Обычно мы входим в систему с компьютеров с Windows 10, используя оболочку git bash (хотя я также использовал putty, чтобы посмотреть, будет ли это иметь значение, но этого не произошло).
В любом случае, я на правильном пути, имея дело с проблемой входа в систему? Проблема в том, что я не могу воспроизвести это по своему желанию. Эта проблема возникает в классе только тогда, когда одновременно выполняется несколько попыток подключения, я вхожу в систему и выхожу из нее без каких-либо проблем в другое время, и никто из учеников не сообщал об этих проблемах в другое время.
Что еще я могу попытаться помочь диагностировать и устранить эту проблему? Я знаю, что, похоже, это тип ошибки, которая возникает у многих, и я прочитал здесь немало, но пока не нашел ни одного рабочего исправления.
ОБНОВИТЬ
Поэтому, когда я пытаюсь воспроизвести эту проблему с помощью этого небольшого скрипта (благодарность @RobbieMckennie за то, что он дал мне эту идею)
LIMIT=5
for i in $(seq $LIMIT)
do
echo
echo "============================= ${i} ==================="
ssh -vvv userid@xx.xx.xxx.xx
echo
done
Я получу это после 3 попыток входа в систему:
$ ssh -vvv useridl@xx.xx.xxx.xx
OpenSSH_7.5p1, OpenSSL 1.0.2k 26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolving "xx.xx.xxx.xx" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to xx.xx.xxx.xx [xx.xx.xxx.xx] port 22.
debug1: connect to address xx.xx.xxx.xx port 22: Connection refused
ssh: connect to host xx.xx.xxx.xx port 22: Connection refused
Фактически, я могу воспроизвести это «вручную», если я быстро вхожу в систему 3 раза, один за другим, 4-я попытка приводит к этому. Исходный IP-адрес находится в моем списке игнорируемых IP-адресов в fail2ban (jail.local
) и, похоже, работает, насколько я могу судить
2017-10-12 07:38:04,481 fail2ban.filter [52845]: WARNING Determined IP using DNS Lookup: c-yy-yy-yy-yyy.hsd1.il.comcast.net = ['yy.yy.yy.yyy']
2017-10-12 07:38:04,482 fail2ban.filter [52845]: INFO [sshd] Ignore yy.yy.yy.yyy by ip
хотя я не уверен, что это предупреждение означает что-нибудь.
Итак, два вопроса:
Что вызывает этот отказ? Насколько я могу судить, я даже не разбираюсь в системе. Есть ли какой-то параметр конфигурации, который мне нужно настроить?
Что еще более важно, когда все мои 22 студента пытаются войти в систему из кампуса, все эти соединения происходят с одного и того же IP-адреса из-за нашего Many-to-1-NAT, может ли это объяснить это? Мне кажется, может (?)
Единственное отличие состоит в том, что ученикам требуется около 15 минут, чтобы войти в систему, когда происходит это отклонение, в то время как в моем эксперименте выше я возвращаюсь в течение нескольких секунд. Может быть, это из-за какого-то отставания?
В частности, я только что обнаружил эту запись в IPtables.
Chain INPUT_direct (1 references)
target prot opt source destination
tcp -- anywhere anywhere tcp dpt:ssh state NEW recent: SET name: DEFAULT side: source mask: 255.255.255.255
REJECT tcp -- anywhere anywhere tcp dpt:ssh state NEW recent: UPDATE seconds: 30 **hit_count: 4** name: DEFAULT side: source mask: 255.255.255.255 reject-with tcp-reset
Это объясняет ограничение в 3 входа в систему, но опять же, я не уверен, что это объясняет 15-минутное ожидание или около того в кампусе, чтобы снова войти в систему, когда мы сталкиваемся с этим.
У меня была аналогичная проблема, и это закончилось тем, что некоторые неприятные боты использовали все несколько слотов для подключения, доступных по умолчанию.
В отличие от того, что мы можем понять из справочных страниц, MaxStartups не будет отбрасывать ожидающие соединения в порядке FIFO при достижении лимита, но будет игнорировать все новые соединения. Поэтому, если у вас установлено значение по умолчанию 10 и 10 человек подключаются, ничего не отправляя, вы больше не сможете войти в систему. По сути, вы хотите, чтобы число было очень большим, если вы не хотите, чтобы кто-то легко заблокировал вас из вашей системы, открыв много соединений (высокий потенциал DoS при настройке по умолчанию).
Здесь задействован еще один параметр: LoginGraceTime. Это время до того, как неаутентифицированный пользователь будет выгнан сервером, который по умолчанию составляет 600 секунд. Это объясняет, почему OP видит задержку около 15 минут, прежде чем студенты смогут войти в систему. Вы хотите, чтобы этот параметр был как можно меньше, чтобы фиктивные соединения можно было быстро удалить.
Я, вероятно, собираюсь связаться с сопровождающим openssh debian, чтобы обсудить эту проблему. Конфигурация по умолчанию не должна быть настолько уязвимой для DoS-атак.
РЕДАКТИРОВАТЬ: я просмотрел отчеты об ошибках, исходный код CVE и openssh. Увеличение MaxStartups оказывает прямое и постоянное влияние на использование ОЗУ, поскольку соединения обрабатываются с использованием одноразового распределения. В основном есть некий "malloc (MAX_STARTUPS * sizeof (connection))". На самом деле, чтобы исправить это, потребуется серьезная переработка того, как openssh обрабатывает выделение памяти, что требует времени, которого никто не имеет.
Я знаю, что опаздываю ;-) но я думаю, у вас работает fail2ban или что-то подобное?
Fail2ban может помочь защитить все виды демонов от грубых атак. Для sshd fail2ban временно блокирует порты для IP-адресов, которые не могут войти в систему повторно. Есть несколько подходов к решению этой ситуации: остановите fail2ban, внесите IP-адрес школы в белый список, ...