ssh_exchange_identification: читайте: Соединение сбрасывается одноранговым узлом
Выполнение этого обычно не имеет смысла. У Вас может быть произвольная сумма сессий и установленных настольных сред. Прежде чем пользователь входит в систему, для системы не возможно знать который к (пред) загрузка. Как следствие необходимо было бы загрузить их всех.
Одна вещь, которую Вы могли сделать, состоит в том, чтобы выяснить, какие файлы загружаются во время типичного запуска для конкретного пользователя:
strace -f -e trace=open <program>
Необходимо запустить сессию с консоли. Я не использую оболочку гнома и таким образом не могу сказать Вам точную команду. Но можно попробовать gnome-session --session gnome-shell или просто startx.
Теперь можно загрузить те файлы в кэш (который хранится в памяти):
cat file > /dev/null
Это должно уменьшить объем данных, загруженный из диска после входа в систему. Но я не знаю, действительно ли это стоит усилия.
] Резкое изменение может быть результатом изменения файла конфигурации на серверах []sshd[], но вы указываете, что не можете проверить или изменить это без права администратора. Вы все еще можете попробовать следующее, если администраторы сервера не могут быть доступны (вовремя).[
]Ваш лог указывает только строку локальной версии, вы должны проверить версии []sshd[], работающие на сервере и промежуточной машине.[
]Если эти версии отличаются (особенно между локальной машиной и сервером и меньше между промежуточной машиной и сервером) может быть некоторая несовместимость переговоров, это []происходило до [] в []sshd[]. Раньше решением было укорачивание записей Ciphers, HostKeyAlgorithms и/или MACs, либо в командной строке ([]ssh -c aes256-ctr[] и т.д.), либо в Вашей []/etc/ssh/ssh_config[]. [
]В качестве аргумента для []-c[]/[]/[]Ciphers[] следует искать в отладочной информации (от соединения через промежуточное звено к серверу) соответствующие значения, []-o HostKeyAlgorithms[]/[]HostKeyAlgorithms[] и []-m[]/[]MACs[] commandline or. ssh_config меняется.[
]Я сам некоторое время не сталкивался с этой проблемой, но IIRC, когда я это сделал, было достаточно вручную форсировать настройку Ciphers и HostKeyAlgorithms, после чего я мог обновить версию сервера []sshd[] и проблема исчезла.[
На главном сервере удалите ssh pub.key, расположенный здесь: ~ / .ssh / authorized_keys для вашего Mac. Затем tail -f /var/log/auth.log, пока вы открываете другой терминал и снова пытаетесь использовать ssh ssh -v me @ server . Если вам будет предложено ввести пароль, значит, проблема с вашим ключом ssh. Если вы все еще видите ответ ssh_exchange_identification: read: Connection reset by peer ', то вы сможете определить, в чем проблема, по записи журнала в файле' /var/log/auth.log 'после неудачной попытки. чтобы залогиниться.
Если вам по-прежнему не удалось подключиться, опубликуйте здесь зарегистрированную запись из файла аутентификации, и я исправлю свой ответ.
Я получил это благодаря серверам имен моих провайдеров в /etc/resolv.conf. Эти серверы имен часто перегружены, и в случае сбоя обратного DNS поиска sshd обрывает соединение. Я решил проблему, используя более надежные сервера имен, например 8.8.8.8.
Я столкнулся с той же проблемой. Я бы успешно открыл сессию ssh, но через некоторое время она бы перезагрузилась. Когда я пытался подключиться немедленно, я получал ошибку "Соединение отказано". Когда я отлаживал сессию, я получал это сообщение в то время, когда соединение обнулялось
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)
debug3: channel 0: close_fds r 4 w 5 e 6 c -1
Read from remote host 10.x.y.z: Connection reset by peer
Connection to 10.x.y.z closed.
debug1: Transferred: stdin 0, stdout 0, stderr 100 bytes in 1029.9 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.1
debug1: Exit status -1
В этот момент я понял, что в сети существует конфликт IP-адресов. Я сменил адрес на другой, и проблема была решена
.Ваш лог означает, что серверная сторона разрывает соединение. Чтобы выяснить причину, вам следует обратиться к лог-файлам на стороне сервера, в них должна быть указана причина разрыва. Вы почти всегда должны быть в состоянии найти логи в /var/log/messages
Я могу догадаться, что, так как соединение обрывается сразу после того, как клиент отправил номер версии, сервер каким-то образом угрожает клиенту, как несовместимый.
Вы можете быть запрещены с помощью Fail2ban или denyhosts . В таком случае (а также проверять его), если вы не хотите беспокоить со помощью провайдера сервера, вам нужно войти в свой сервер с другого IP-адреса: E.g. Другой сервер или домашнее соединение друга, или для горячего места WiFi или с использованием SSH с Tor.
После входа в систему, убедитесь, что ваш IP-адрес действительно появляется в /etc/hosts.deny (на стороне сервера). Если так, то Fail2ban или Denyhosts действительно должен быть виновником.
См. Ответы на этот вопрос для процедуры предотвращения Denyhosts , чтобы непрерывно заблокировать ваш адрес. Для Fail2ban Найти свой IP с IPTables -l --line-Number и Unban You IP с IPTables -d , вы проверяете Детали на HowtoForge .
Возможно, вы захотите добавить свой IP-адрес в Fail2ban и Denyhosts Whitelists (соответственно /etc/fail2ban/jail.conf , Line Lineipip , и / var / lib / denyhosts / допускаемые хозяева , создайте его при необходимости (но остерегайтесь, что путь может отличаться в вашем распределении)), чтобы предотвратить попытку проблемы.
Я знаю, что этот вопрос старый, но я хотел бы поделиться некоторыми своими выводами. Проверьте, имеет ли /var/empty/sshd на сервере соответствующие права собственности и разрешения.
У нас был сценарий шеф-повара, который был изменен для обновления некоторых прав доступа к каталогам, но случайно обновил каталог ниже предполагаемой цели, изменив права собственности на /var для пользователя/группы приложений и изменив права доступа на 775.
Это может произойти, если у вас в сети несколько машин с одним и тем же MAC-адресом (например, если вы сделаете копию виртуальной машины и забудете поменять MAC-адрес).
У меня была та же проблема, но оказалось, что причина была в другом: я использовал неправильный порт.
В новых версиях ssh выдается сообщение об ошибке Отказ в соединении или Неверный порт.
В более старых версиях выдается ошибка ssh_exchange_identification: read: Connection reset by peer
Поэтому, когда вы получаете такую ошибку, проверьте правильность порта.
Поскольку это не было указано явно в ответе, эта ошибка может появиться и в другом случае, если сетевой брандмауэр -между вами и сервером решил заблокировать соединение. Брандмауэр мог решить, что было «слишком много» подключений с IP-адреса системы OS X, и начать его блокировать. Соединений из другой системы еще не было «слишком много», поэтому это было разрешено.
Последнее сообщение, которое вы получили от сервера, появилось еще до того, как вы начали какие-либо попытки аутентификации, что исключает большой класс возможностей, связанных с вашей учетной записью, ключом или паролем.
Примеры такой политики грубой -силы от случайной выборки поставщиков::
- CloudFlare :Как использовать ограничение скорости для защиты от атак грубой -силы?
- F5 :Настройка защиты от грубой силы
- FortiNet :создание пользовательской сигнатуры IPS для определения частоты шаблонов -пример обнаружения атаки грубой силы -
- Пало-Альто :Предотвращение атак грубой силы
- Sonicwall :Как блокировать атаки грубой силы и словаря с помощью SRA
Я столкнулся именно с этой ошибкой при попытке подключиться к всем моим удаленным хостам через опцию моста Wi -Fi на моем устройстве Android (Huawei P30 Pro ). Когда я использовал опцию USB-модема для совместного использования одного и того же интернет-соединения, проблем не возникло.
Абсолютно ничего не изменилось в конфигурации или параметрах SSH на клиенте или серверах.
TL;DR:иногда ничего не поделаешь.