SSH-соединение “client_loop: send disconnect: Broken pipe” или “Connection reset by порт 22”

Я использую ssh для доступа к удалённым серверам в течение многих месяцев, но недавно я не могу установить надёжное соединение. Иногда я не могу войти в систему и получаю сообщение “Connection reset by порт 22”, когда могу войти, появляется сообщение об ошибке “client_loop: send disconnect: Broken pipe” через несколько минут (даже если терминал не простаивает).

Мой файл ~/.ssh/config содержит:

Host *  

     ServerAliveInterval 300
     ServerAliveCountMax 2
     TCPKeepAlive yes

Мой файл /etc/ssh/sshd_config содержит:

#ClientAliveInterval 300
#ClientAliveCountMax 3

Недавно я обновил свой тарифный план xfinity на более высокую скорость, и проблема началась с тех пор. Но xfinity утверждает, что проблема на моей стороне. Заметьте, что у моего соседа по комнате также есть такая же проблема с ssh…

Мне чего-то не хватает с моей стороны? Любая помощь будет очень полезна!
(Я использую Mac)

Я решил ту же проблему, изменив файл ~/.ssh/config на:

Host *
    ServerAliveInterval 20
    TCPKeepAlive no

Мотивация:

TCPKeepAlive no означает “не отправлять keepalive-сообщения на сервер.” Когда установлено противоположное, TCPKeepAlive yes, клиент отправляет keepalive-сообщения на сервер и требует ответа, чтобы поддерживать своё соединение. Это обнаружит, если сервер выйдет из строя, перезагрузится и т.д. Проблема в том, что если соединение между клиентом и сервером прерывается на короткое время (из-за нестабильного сетевого соединения), это приведет к сбою keepalive-сообщений, и клиент разорвет соединение с “broken pipe”.

Установка TCPKeepAlive no говорит клиенту просто предполагать, что соединение все еще в порядке, пока не будет доказано обратное по запросу пользователя, то есть временные сбои соединения, пока ваша сессия ssh простаивает в фоновом режиме, не прервут соединение.

Ответ Дэвида хорош, но более комплексное решение объясняется ниже.

Эту проблему можно решить как на стороне клиента, так и на стороне сервера.

Как узнать, где это сделать?

• Настройте это на своем устройстве, если вы подключаетесь по SSH к нескольким серверам.

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

Клиентская сторона

При подключении к серверу используйте опцию -o:

ssh -o ServerAliveInterval=600 [email protected]

Значение 600 представляет 600 секунд, то есть 10 минут.

Альтернативно, добавьте это в ваш файл конфигурации ssh:

1. Создайте файл конфигурации ssh (если он не существует):

   touch ~/.ssh/config
   

2. Установите разрешения:

   chmod 600 ~/.ssh/config
   

3. Установите параметр в файле конфигурации. Например:

   echo "ServerAliveInterval 600" >> ~/.ssh/config
   

   … или используйте редактор.

Серверная сторона

1. Откройте файл конфигурации sshd, расположенный по пути /etc/ssh/sshd_config.
2. Установите параметры ClientAliveInterval и ClientAliveCountMax на желаемые значения.

Например, ClientAliveInterval=200 и ClientAliveCountMax=3 означает, что сервер отправит alive-сообщение через 200 секунд. Если клиент не ответит, он повторно отправит alive-сообщение через 400 секунд. Если клиент все еще не ответит, он отправит еще одно alive-сообщение через 600 секунд. Если ответа все равно не будет, SSH-соединение будет разорвано.

Источник: Исправление ошибки Broken Pipe с SSH-соединением в Linux Handbook.

У меня была эта проблема, когда я пытался подключиться по SSH к ноутбуку с Windows с моего Mac. Я пробовал вышеупомянутые решения касательно ServerAliveInterval и TCPKeepAlive, но безуспешно.

Я не совсем уверен, почему это сработало, но я решил проблему, удалив свой открытый ключ SSH из файла ~/.ssh/authorized_keys на удалённом ноутбуке. Это было особенно странно, потому что, согласно моему логу ssh -v, мой открытый ключ, казалось, работал для аутентификации нормально:

debug1: Authentication succeeded (publickey).
Authenticated to 192.168.1.21 ([192.168.1.21]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: filesystem full
client_loop: send disconnect: Broken pipe

В любом случае, удаление ключа помогло мне обойти ошибку client_loop: send disconnect: Broken pipe, и теперь я могу войти в систему.

У меня была точно такая же ошибка только для одного конкретного пользователя, так скажем: X. После того как я попробовал всё, что было описано здесь, я понял, что добавил пользователю X группу пользователя Y. Но пользователю Y не разрешено входить через ssh. После удаления X из группы Y я смог снова войти в систему.

Надеюсь, это тоже кому-то поможет.

Вы можете решить эту проблему, если используете подсистему, тогда вам нужно убедиться, что владельцем этих данных должен быть root, а также права должны быть ограничены

У меня также была эта проблема

Client_loop: send disconnect: broken pipe

Потому что я дал все права всем другим пользователям, это и создавало проблему

И посмотрев в /var/log/auth.log, я обнаружил ошибку, что я дал полные права всем пользователям, и это было причиной проблемы.

После изменения прав я успешно подключился. Я был удивлен, что это из-за излишних прав

sudo chown root:root /rooted/Environment 
sudo chmod 755 /rooted/Environment 

Я столкнулся с этой проблемой, когда пытался подключиться к Windows SSH серверу из Linux-скрипта (для автоматизации).

Оказалось, что OpenSSH на Windows очень плохо определяет, какую оболочку запускать. Эта команда завершилась с ошибкой:

echo "dir" | ssh -T user@windows-host

Но явная спецификация cmd.exe как оболочки сработала:

echo "dir" | ssh -T user@windows-host cmd.exe

В основном оставляю это здесь как подсказку для самого себя в будущем.

Еще одна возможная причина неясного сообщения об ошибке: Неправильное владение каталогом при использовании ChrootDirectory.

Если SSH требует /home/USERNAME в качестве chroot, он должен быть в собственности root и должен иметь строгие права. Если пользователь, вошедший в систему, владеет chroot-директорией, подключения по SSH и SFTP будут завершаться ошибкой.

Вы можете проверить эти настройки в /etc/ssh/sshd_config или файле в /etc/ssh/sshd_config.d/*.conf.

Match User USERNAME
        ForceCommand internal-sftp
        PasswordAuthentication yes
        PubkeyAuthentication yes
        ChrootDirectory /home/USERNAME

В моем случае, пользователь был настроен для доступа только к SFTP, а chroot оставлял его в пределах нужной области. Разрешения на их домашний каталог были случайно сброшены. Когда я вернул владельца обратно на root, всё стало нормально.