Если не мы, то кто занял VTY SSH линии? Это OPS
Недавно расследовали кейс, когда при следующей конфигурации (см. ниже) все попытки залогиниться на маршрутизатор Huawei NE40E-X8A (V800R021C00SPC100) были неуспешны в течение около двадцати минут, при этом все линии VTY SSH линии были свободны, никто не логинился на устройство несколько дней. Всего было настроена 21 VTY линия для доступа (user-interface maximum-vty 21).
user-interface vty 0 4
authentication-mode aaa
protocol inbound ssh
Маршрутизатор возвращал такие ошибки как: VTY not available for Stelnet connection, User public key authentication failed, The authentication server has no response:
Траблшутинг осложнился тем, что пользователь после нескольких неудачных попыток начал перебирать имя пользователя, полагая, что ввел его неверно. Это привело к блокировке IP-адреса-источника запросов (на маршрутизаторе был включен ssh server ip-block). В итоге зайти удалось только минут через двадцать с контроллера iMasterNCE под другой учеткой.
Ни диагностический файл, ни типовые логи не дали почти никакой информации о причине случившегося. Только операционные логи (файл log.log) показали, что OPS занимал все линии VTY по SSH, отрабатывая свои задания. OPS - это встроенный в прошивку инструмент, который позволяет использовать Python код для автоматизации. Название так и расшифровывает Open Programmability System.
Несмотря на то, что VTY линий для доступа было настроено 21, но только 5 из них (vty 0 4) были настроены для SSH доступа. И OPS периодически занимал их все.
Чтобы избежать подобного сценария в будущем, следовало внести изменения в конфигурацию:
user-interface vty 0 20
authentication-mode aaa
protocol inbound ssh
Это касается не только Huawei модели NE40, но и всех прочих продуктов Huawei, работающих с OPS, например, серии коммутаторов CloudEngine.