. Для устранения проблемы:
Вы должны убедиться, что ssh не имеет пользовательской конфигурации в ~ / .ssh / config
Лучшим способом было бы временно переместить файл, переименовав его (не полагайтесь на редактирование содержимого и полагайте, что все в порядке, вы все равно устраняете неполадки):
mv -i ~ /.ssh/config ~ / .ssh / config _
Вышеупомянутого (как мы знаем из комментариев) было достаточно, чтобы изолировать проблему, однако, если это не так:
Проверьте / etc / ssh / ssh_config
для любых индивидуальных настроек хоста. По умолчанию существует только раздел Host *
.
Если какое-то перенаправление все еще происходит, изолируйте шаг за шагом:
Проверьте результаты хоста telnet 22
и сравните результат с ssh
- если IP-адрес назначения перенаправлен в обоих В некоторых случаях это указывало бы на какое-то странное перенаправление сети.
Отключите машину от сети и проверьте перенаправление, если происходит, значит проблема в машине.Если нет (что маловероятно), проверьте сетевое окружение, прокси, DNS и т. Д.
Используйте / создайте нового пользователя и проверьте ssh
из другой учетной записи, если перенаправление не происходит, перепроверьте индивидуальные настройки исходного пользователя.
Убедитесь, что вы используете исходный ssh
, с помощью следующих команд:
$ which ssh
/ usr / bin / ssh
$ file / usr / bin / ssh
/ usr / bin / ssh: 64-разрядный общий объект LSB ELF, x86-64, версия 1 (SYSV), динамически связанный (использует общие библиотеки), для GNU / Linux 2.6.24, BuildID [sha1 ] = 3ec70221b7cac9eebe63dadbe871bc49359a7dfe, stripped
Если результаты отличаются, возможно, вы запускаете оболочку оболочки, выполняющую ssh
с параметрами, определенными в сценарии.
Я бы определенно сделал отфильтрованный pcap трафика. Это опасная аутентификация, особенно если кажется, что она имеет и авто-маршрут.