Я могу использовать SSH в одном направлении без проблем:
ОК:
ssh user@computerAно в другую сторону:
ssh user@computerBЯ получаю Read from socket failed: Connection reset by peer.
Я даже не начинаю понимать, где искать решение этой проблемы.
У кого-нибудь есть какие-нибудь зацепки?
начните мониторинг файла журнала сервера
tail -f /var/log/auth.log
add -v для получения подробного вывода на стороне клиента
ssh user@computerB -v
Это может дать вам более подробную информацию о причине. если на сервере отсутствуют ключи rsa и dsa, исправьте их с помощью:
ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_rsa_keyssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_keyЯ переустановил биты SSH, выполнив:
sudo apt-get --reinstall install openssh-server openssh-clientЭто устранило все мои проблемы.
у ахракса метод очень полезен. Это работает для меня!
В принципе, я думаю, что после установки ssh необходимы файлы ключей.
Единственное изменение, которое я внес, состояло в том, чтобы использовать rsa вместо rsa1:
ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_keyЭтот модифицированный метод сработал для меня.
Это потому, что каким-то образом права доступа к файлам внутри /etc/ssh изменились...Поэтому измените разрешение файлов, как в примере, приведенном ниже:
использовать:
chmod 644 ssh_configchmod 600 moduliи так далее...
Наконец, права доступа к файлам должны выглядеть примерно так, как показано ниже,
[root@hostname ssh]# ls -latrtotal 172-rw-r--r--. 1 root root 2047 Aug 12 2010 ssh_config-rw-------. 1 root root 125811 Aug 12 2010 moduli-rw-------. 1 root root 963 Mar 1 16:02 ssh_host_key-rw-r--r--. 1 root root 627 Mar 1 16:02 ssh_host_key.pub-rw-r--r--. 1 root root 382 Mar 1 16:02 ssh_host_rsa_key.pub-rw-------. 1 root root 1675 Mar 1 16:02 ssh_host_rsa_key-rw-r--r--. 1 root root 590 Mar 1 16:02 ssh_host_dsa_key.pub-rw-------. 1 root root 668 Mar 1 16:02 ssh_host_dsa_key-rw-------. 1 root root 3845 May 7 11:52 sshd_configПосле изменения разрешений попробуйте подключиться из putty, должно работать нормально..
У нас была похожая проблема, но она возникла только при входе из Ubuntu в Solaris. Убедившись, что все эти строки присутствуют в /etc/ssh/ssh_config на хосте Ubuntu исправлена проблема (вы должны обнаружить, что некоторые из этих строк уже присутствуют):
Host *SendEnv LANG LC_*HashKnownHosts yesGSSAPIAuthentication yesGSSAPIDelegateCredentials noCiphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbcHostKeyAlgorithms ssh-rsa,ssh-dssMACs hmac-md5,hmac-sha1,hmac-ripemd160В случае с Xubuntu мне нужны были только последние два.
Это сообщение также может быть вызвано несколькими попытками ssh-атак. Если вы видите это сообщение в своих журналах, возможно, вредоносный источник пытается подключиться к вашему компьютеру по ssh с помощью попыток ввода пароля методом перебора.
Чтобы замедлить попытки, установите пакет "fail2ban".:
sudo apt-get install fail2banFail2ban сканирует файлы журналов (например, /var/log/ apache/error_log) и запрещает IP-адреса, которые показывают вредоносные признаки - слишком много сбоев пароля, поиск эксплойтов и т.д. Обычно Fail2Ban затем используется для обновления правил брандмауэра, чтобы отклонять IP-адреса в течение определенного периода времени
Какова ваша сетевая конфигурация? Находится ли какая-либо машина за брандмауэром / маршрутизатором?
Оба просто подключены друг к другу по кабелю Ethernet через маршрутизатор. В прошлом они работали по SSH в обоих направлениях.
Вы проверили, что оба SSH-демона запущены? Что-нибудь есть в журналах?
Хорошие и плохие новости: я ответил на свой собственный вопрос. Я напишу это ниже. Все равно спасибо за вашу помощь.