☰

Почему мой вход по SSH сбрасывается сразу после входа?

tag-icon • tag-icon linux ubuntu ssh
Почему мой вход по SSH сбрасывается сразу после входа?

Я пытаюсь подключиться с MacBook Air (MacOS 10.14.6) через ssh (без пароля) к машине Ubuntu (16.04.6), используя команду типа

ssh aaa.bbb.ccc.ddd

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

Однако уже около недели это больше не работает, хотя я не вносил никаких изменений в процесс входа в систему, не создавал новых пользователей, не менял пароль, не менял ключи, не обновлял ОС, не менял .profileи .bashrcт. д. Я также проверил /etc/hosts.allow, но /etc/hosts.denyтам ничего нет, и перезагрузил машину с Ubuntu и Mac, но никаких изменений.

В момент успешного входа я вижу сообщение

Last login: ... from www.xxx.yyy.zzz
Connection to aaa.bbb.ccc.ddd closed

Как я могу отладить то, что происходит?

Приложение

При проверке /var/log/auth.logя вижу следующие записи:

Oct 16 07:02:38 mac353 systemd-logind[1173]: New session 11 of user alex.
Oct 16 07:02:38 mac353 sshd[11834]: Received disconnect from www.xxx.yyy.zzz port 61437:11: disconnected by user
Oct 16 07:02:38 mac353 sshd[11834]: Disconnected from www.xxx.yyy.zzz port 61437

решение1

Oct 16 07:02:38 mac353 sshd[11834]: Received disconnect from www.xxx.yyy.zzz port 61437:11: disconnected by user

Правильный ли www.xxx.yyy.zzzIP-адрес у вашего MacBook Air на данный момент?

Может быть, в сети есть другая система, использующая тот же IP-адрес. Вы можете инициировать соединение обычным образом, но любые ответы будут доставлены случайным образом обеим системам, участвующим в конфликте IP-адресов, поэтому серверу, возможно, придется повторно отправить некоторые из своих исходящих пакетов. Обычно система, которая на самом деле активно пытается установить соединение, ответит быстрее, поэтому для нескольких начальных пакетов может показаться, что все работает нормально.

Но в конце концов драйвер TCP/IP конфликтующей системы подумает: «Что это за трафик? У меня сейчас нет такого активного TCP-соединения». и отправит пакет TCP Reset обратно источнику ложного трафика, то есть серверу. Поскольку конфликтующая система имеет тот же IP-адрес, что и ваш MacBook, сервер не может узнать, что TCP Reset на самом деле не относится к вашему соединению, и поэтому сервер предположит, что TCP Reset означаеттыхотел отключиться. Это не происходит немедленно, поскольку отправка пакетов сброса TCP обычно является низкоприоритетной задачей в драйвере TCP/IP.

Это весьма типичный симптом конфликта IP-адресов.

Чтобы найти конфликтующую систему, вы можете попробовать просмотреть таблицы MAC-адресов сетевого коммутатора (если это управляемый коммутатор) или точки доступа WiFi вашего локального сегмента сети. Если ваш IP-адрес связан с MAC-адресом, который не принадлежит вашему MacBook, вы нашли MAC-адрес конфликтующей системы. В проводной сети вы можете проверить, какой порт коммутатора увидел этот MAC-адрес, а затем просто посмотреть, что находится на другом конце кабеля.

Если у вас нет управляемых коммутаторов или доступа к ним, вы можете попробовать пинговать свой собственный IP-адрес и посмотреть, получите ли вы дублирующиеся ответы. Или вы можете попробовать инструмент arpingкомандной строки, чтобы сделать то же самое с пакетами ARP: это поймает даже системы, которые не отвечают на пинги.

решение2

Решение этой проблемы было set -eв файле, /etc/profile.dкоторый был установлен в совершенно другом контексте. После переименования этого файла sshвход снова заработал.

`set -e`

останавливает выполнение скрипта, если команда содержит ошибку (глянь сюда) и некоторые считают это плохой практикой.

Связанный контент