Linux ssh рвется сессия

Регулярные обрывы ssh подключений. (Broken pipe)

Регулярно раз в несколько часов рвётся соединение по ssh.

packet_write_wait: Connection to . port 22: Broken pipe

Два нетбука подключены к серверу с внешним ip. оба одновременно выбрасывает. Если подключаться внутри домашней сети 192.168.x.x то ничего не рвётся.

Я подозреваю обрывы связи у провайдера. Однако как думаете, может ли быть проблема на моей стороне, а не у него?

не знаю насчет провайдера, но иногда рекомендую https://habr.com/ru/post/243651/

Глянул лог: journalctl -u sshd |tail -100 Вот ещё долбятся ко мне безуспешно какие-то боты c ником admin, хотел забанить, но почему-то не работают записи в /etc/hosts.allow и /etc/hosts.deny. Например безуспешно пробовал забанить себя:

Регулярно раз в несколько часов рвётся соединение по ssh.

Не будет разрывов.

Стоит попробовать ServerAliveInterval и ServerAliveCountMax в конфиге.

подозреваю обрывы связи у провайдера

Лично на моей практике — с годами разные хосты и интернеты — это норма, мало ли что за час(-ы) в сети происходит. Для коротких сессий это вообще не страшно, для длинных есть nohup или https://www.howtogeek.com/howto/ubuntu/keep-your-ssh-session-running-when-you. , зависимо от интерактивности.

долбятся ко мне безуспешно какие-то боты c ником admin, хотел забанить

Не надо, у тебя же по ключу аутентификация, а не по паролю.

У провайдера NAT поди? Про ServerAliveInterval уже написали, вот его и используй.

Спасибо, ServerAliveInterval 120 вписал.

Не надо, у тебя же по ключу аутентификация, а не по паролю.

Чтобы лог не засирали. И почему эти файлы в Manjaro не работают, не понимаю.

Скорее всего да. Уже не помню точно. Внешний Ip бывает и динамический дают, а у них пришлось покупать опцию за бабоссики на статичный.

Источник

Соединение через SSH постоянно сбрасывается (обрывается)

Раз вы читаете эту статью, то скорей всего столкнулись с такой проблемой, что ваши удаленные SSH сессии, которые открыты с помощью стандартных средств Linux, вроде ssh или sftp , или же через Putty , в случае работы с компьютера под управлением Windows, постоянно сбрасываются и обрываются. Хотя само интернет соединение на вашем компьютере с виду работает исправно, это не помогает от разрывов.

Описание

Основными причинами, по которым ваши подключения обрываются могут быть:

• Очень плохое подключение к сети/интернету, потери пакетов и высокий пинг;
• На некоторых серверах по умолчанию стоят настройки, которые обрывают SSH сессии в случае долго бездействия;
• Некоторые модели роутеров обрывают соединения, если они долгое время не активны;

Локальный способ для Linux (ssh)

Для всех исходящих SSH сессий

Если такая проблема присутствует у вас при подключении к различным серверам и везде рвутся соединения после определенного периода бездействия, то скорей всего проблема на вашей стороне. Исправить это можно явно задав соответствующие опции для ssh .

Для этого открываем файл /etc/ssh/ ssh _config и в самый низ этого файла добавляем следующие строчки:

ServerAliveInterval 60 — Данный параметр определяет как часто ваш ПК с которого установлена SSH сессия (клиент) будет отправлять на сервер SSH к которому вы подключились пакет, говорящий «я живой». В нашем примере это будет происходить каждые 60 секунд.
ServerAliveCountMax 5 — Данный параметр определяет, сколько раз такой пакет «я живой» будет отправлен на сервер в том случае, когда от сервера не последовало ответа, прежде чем принудительно разорвать соединение. В нашем примере 5 раз.
С такими настройками сессия будет висеть 60 * 5 = 300 секунд, после чего автоматически оборвется (только в случае, когда сервер вам не отвечает 5 раз подряд).

После внесения этих изменений, к любому новому соединению через ssh или sftp должны применяться эти настройки.

Для выборочных исходящих SSH сессий

Если вы не хотите менять параметры для ssh через файл конфигурации, то существует способ указывать эти настройки только для определенных хостов, для этого вводим команду для соединения вот таким образом:

Локальный способ для Windows

Putty

На ОС Windows очень часто в качестве ssh клиента используется Putty. В данном клиенте также есть настройки, позволяющие избежать разрыва ssh сессий. Находятся они вот тут:

Connection -> Sending of null packets to keep session active -> Seconds between keepalives (0 to turn off)

Задаем значение, например 60 и пытаемся подключиться.

WinSCP

Эти же настройки есть и в программе WinSCP. Найти их можно следующим способом:

В начальном окне программы необходимо выбрать нужное соединение и нажать на кнопку «Редактировать», а затем на кнопку «Еще».

В открывшихся свойствах соединения нужно выбрать раздел «Подключение» и там в пункте «Поддерживать активность» отметить «Пустые команды протокола», и задать значение «Секунд между сообщениями» — например, 10.

Если же вы пользуетесь каким-то другим клиентом, в котором нет подобных опций, тогда вам необходимо переходить к следующему пункту и изменить настройки на самом сервере, к которому вы подключаетесь.

Удаленный способ Linux & Windows

Если проблема с постоянным разрывом SSH сессий присутствует только на одном определенном сервере, то тогда можно в его конфигурации sshd сделать небольшие изменения, чтобы решить эту проблему. Для этого открываем файл /etc/ssh/ sshd _config и в самый низ конфигурации дописываем следующие настройки:

ClientAliveInterval 60 — Данный параметр определяет как часто сервер, к которому вы подключены, будет отправлять на ваш компьтер (клиент) пакет, говорящий «я живой». В нашем примере это будет происходить каждые 60 секунд.
ClientAliveCountMax 5 — Данный параметр определяет, сколько раз такой пакет «я живой» будет отправлен от сервера на ваш клиентский ПК, когда от вашего ПК не последовало ответа, прежде чем принудительно разорвать соединение. В нашем примере 5 раз.
С такими настройками сессия будет висеть 60 * 5 = 300 секунд, после чего автоматически оборвется (только в случае, когда клиент не отвечает 5 раз подряд).

После внесения изменений в конфиг, необходимо перезапустить службу sshd на сервере, сделать это можно следующей командой:

И попытаться подключиться к нему через ssh.

Источник

Устранение неполадок SSH: проблемы с подключением к серверу

В первой статье этой серии вы узнали о том, как и в каких ситуациях вы можете попробовать исправить ошибки SSH. Остальные статьи расскажут, как определить и устранить ошибки:

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

Для взаимодействия SSH-клиента с SSH-сервером необходимо установить базовое сетевое подключение. Это руководство поможет определить некоторые общие ошибки подключения, исправить их и предотвратить их возникновение в будущем.

Требования

• Убедитесь, что можете подключиться к виртуальному серверу через консоль.
• Проверьте панель на предмет текущих проблем, влияющих на работу и состояние сервера и гипервизора.

Основные ошибки

Разрешение имени хоста

Большинство ошибок подключения возникает тогда, когда ссылка на хост SSH не может быть сопоставлена с сетевым адресом. Это почти всегда связано с DNS, но первопричина часто бывает не связана с DNS.

На клиенте OpenSSH эта команда:

может выдать ошибку:

ssh: Could not resolve hostname example.com: Name or service not known

В PuTTY может появиться такая ошибка:

Unable to open connection to example.com Host does not exist

Чтобы устранить эту ошибку, можно попробовать следующее:

• Проверьте правильность написания имени хоста.
• Убедитесь, что вы можете разрешить имя хоста на клиентской машине с помощью команды ping. Обратитесь к сторонним сайтам (WhatsMyDns.net, например), чтобы подтвердить результаты.

Если у вас возникают проблемы с разрешением DNS на любом уровне, в качестве промежуточного решения можно использовать IP-адрес сервера, например:

ssh user@111.111.111.111
# вместо
ssh user@example.com.

Истечение времени соединения

Эта ошибка значит, что клиент попытался установить соединение с SSH-сервером, но сервер не смог ответить в течение заданного периода ожидания.

На клиенте OpenSSH следующая команда:

выдаст такую ошибку:

ssh: connect to host 111.111.111.111 port 22: Connection timed out

В PuTTY ошибка выглядит так:

Network error: Connection timed out

Чтобы исправить ошибку:

• Убедитесь, что IP-адрес хоста указан правильно.
• Убедитесь, что сеть поддерживает подключение через используемый порт SSH. Некоторые публичные сети могут блокировать порт 22 или пользовательские SSH-порты. Чтобы проверить работу порта, можно, например, попробовать подключиться к другим хостам через этот же порт. Это поможет вам определить, не связана ли проблема с самим сервером.
• Проверьте правила брандмауэра. Убедитесь, что политика по умолчанию – не DROP.

Отказ в соединении

Эта ошибка означает, что запрос передается на хост SSH, но хост не может успешно принять запрос.

На клиенте OpenSSH следующая команда выдаст ошибку:

ssh user@111.111.111.111
ssh: connect to host 111.111.111.111 port 22: Connection refused

В PuTTY ошибка появится в диалоговом окне:

Network error: Connection refused

Эта ошибка имеет общие с ошибкой Connection Timeout причины. Чтобы исправить её, можно сделать следующее:

• Убедиться, что IP-адрес хоста указан правильно.
• Убедиться, что сеть поддерживает подключение через используемый порт SSH. Некоторые публичные сети могут блокировать порт 22 или пользовательские SSH-порты. Чтобы проверить работу порта, можно, например, попробовать подключиться к другим хостам через этот же порт.
• Проверить правила брандмауэра. Убедитесь, что политика по умолчанию – не DROP, и что брандмауэр не блокирует этот порт.
• Убедиться, что сервис запущен и привязан к требуемому порту.

Рекомендации по исправлению ошибок подключения

Брандмауэр

Иногда проблемы с подключением возникают из-за брандмауэра. Он может блокировать отдельные порты или сервисы.

В разных дистрибутивах используются разные брандмауэры. Вы должны научиться изменять правила и политики своего брандмауэра. В Ubuntu обычно используется UFW, в CentOS – FirewallD. Брандмауэр iptables используется независимо от системы.

Читайте также:

Чтобы настроить брандмауэр, нужно знать порт сервиса SSH. По умолчанию это порт 22.

Чтобы запросить список правил iptables, введите:

Такой вывод сообщает, что правил, блокирующих SSH, нет:

Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Если в выводе вы видите правило или политику по умолчанию REJECT или DROP, убедитесь, что цепочка INPUT разрешает доступ к порту SSH.

Чтобы запросить список правил FirewallD, введите:

Список, появившийся на экране, содержит все сервисы, которые поддерживаются брандмауэром. В списке должно быть правило:

dhcpv6-client http ssh

Если вы настроили пользовательский порт SSH, используйте опцию –list-ports. Если вы создали пользовательское определение сервиса, добавьте опцию –list-services, чтобы найти SSH.

Чтобы проверить состояние UFW, введите:

Команда вернёт доступные порты:

Status: active
To Action From
— —— —-
22 LIMIT Anywhere
443 ALLOW Anywhere
80 ALLOW Anywhere
Anywhere ALLOW 192.168.0.0
22 (v6) LIMIT Anywhere (v6)
443 (v6) ALLOW Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)

В списке должен быть порт SSH.

Проверка состояния сервиса SSH

Если вы не можете подключиться к серверу по SSH, убедитесь, что сервис SSH запущен. Способ сделать это зависит от операционной системы сервера. В более старых версиях дистрибутивов (Ubuntu 14.04, CentOS 6, Debian 8) используется команда service. Современные дистрибутивы на основе Systemd используют команду systemctl.

Метод проверки состояния сервиса может варьироваться от системы к системе. В более старых версиях (Ubuntu 14 и ниже, CentOS 6, Debian 6) используется команда service, поддерживаемая системой инициализации Upstart, а в более современных дистрибутивах для управления сервисом используется команда systemctl.

Примечание: В дистрибутивах Red Hat (CentOS и Fedora) сервис называется sshd, а в Debian и Ubuntu – ssh.

В более старых версия используйте команду:

service ssh status

Если процесс работает должным образом, вы увидите вывод, который содержит PID:

ssh start/running, process 1262

Если сервис не работает, вы увидите:

В системах на основе SystemD используйте:

systemctl status sshd

В выводе должна быть строка active:

sshd.service — OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
Active: active (running) since Mon 2017-03-20 11:00:22 EDT; 1 months 1 days ago
Process: 899 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)
Main PID: 906 (sshd)
CGroup: /system.slice/sshd.service
├─ 906 /usr/sbin/sshd -D
├─26941 sshd: [accepted] └─26942 sshd: [net]

Если сервис не работает, вы увидите в выводе inactive:

sshd.service — OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
Active: inactive (dead) since Fri 2017-04-21 08:36:13 EDT; 2s ago
Process: 906 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=0/SUCCESS)
Process: 899 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)
Main PID: 906 (code=exited, status=0/SUCCESS)

Чтобы перезапустить сервис, введите соответственно:

service ssh start
systemctl start sshd

Проверка порта SSH

Существует два основных способа проверить порт SSH: проверить конфигурационный файл SSH или просмотреть запущенный процесс.

Как правило, конфигурационный файл SSH хранится в /etc/ssh/sshd_config. Стандартный порт 22 может переопределяться любой строкой в этом файле, определяющей директиву Port.

Запустите поиск по файлу с помощью команды:

grep Port /etc/ssh/sshd_config

Если вы уже убедились, что сервис работает, теперь вы можете узнать, работает ли он на требуемом порте. Для этого используйте команду ss. Команда netstat –plnt выдаст аналогичный результат, но команду ss рекомендуется использовать для запроса информации сокета из ядра.

В выводе должно быть указано имя программы и порт, который она прослушивает. Например, следующий вывод сообщает, что сервис SSH прослушивает все интерфейсы и порт 22.

State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 *:22 *:* users:((«sshd»,pid=1493,fd=3))
LISTEN 0 128 . 22 . * users:((«sshd»,pid=1493,fd=4))

Символ * и 0.0.0.0 указывает, что все интерфейсы сервера прослушиваются. Строка 127.0.0.1 значит, что сервис не является общедоступным. В sshd_config директива ListenAddress должна быть закомментирована, чтобы прослушивать все интерфейсы, или должна содержать внешний IP-адрес сервера.

Если у вас не получается самостоятельно настроить соединение SSH, вы можете обратиться за помощью к службе поддержки своего хостинг-провайдера.

Источник