ssh: Читайте из отказавшего сокета: Соединение сбрасывается одноранговым узлом
В Unix файл (или любой объект файловой системы) представлен inode (косвенный узел). Вся информация о файле (размер, метки времени, полномочия) хранится в inode, каталог является по существу просто файлом, отображающим имена к inodes. inode может несколько раз упоминаться в том же каталоге с различными именами или в различных каталогах. Каждый будет точно тем же файлом, нет никакого основного устройства и вторичных устройств здесь. Одни из данных в inode являются количеством ссылок, удаление файла просто стирается, имя формируют каталог и сокращают число ссылок. Когда количество достигает 0, файл не может больше находиться и может также быть уничтожен. Каждое из упоминаний о файле называют жесткой ссылкой.
Символьная ссылка является по существу специальным файлом, который содержит название файла. Каждый раз, когда по символьной ссылке переходят, содержавшее имя файла читается, и тот файл затем обычно ищется. Обратите внимание, что цель символьной ссылки, возможно, хорошо была удалена, нет никакого способа знать, где такие ссылки могли бы существовать для исправления их. Результатом является неработающая ссылка.
Полномочия на символьной ссылке абсолютно не важны, что релевантно, полномочия на пути к цели. Традиционно символьные ссылки имеют (восьмеричное) разрешение 0777.
Обратите внимание, что существуют некоторые ограничения: Жесткие ссылки могут быть добавлены в файл только в той же файловой системе (inodes, известны локально только), и не может обратиться к каталогам (за исключением . и .. записи). Последнее должно избежать циклов, которые потребовали бы, чтобы дорогостоящая сборка "мусора" узнала, может ли что-то быть удалено или нет.
Символьные ссылки могут пересечь файловые системы и могут указать на каталоги. Но они подвергаются полномочиям пути, указал и может быть поврежден.
В конфигурационном файле клиента (/etc/ssh/ssh_config) некомментированные строки 42 и 43.
Похоже, это вопрос разрешения, разрешение для
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_dsa_key
должно быть таким, чтобы другие пользователи не могли получить доступ к этим ключам.
изменил разрешение на 700 вместо 755
[root@SC-1 ssh]# ls -l
total 156
-rwxr-xr-x. 1 root root 125811 Nov 21 2013 moduli
-rwxr-xr-x. 1 root root 2047 Nov 21 2013 ssh_config
-rwxr-xr-x. 1 root root 3879 Nov 21 2013 sshd_config
-rwxr-xr-x. 1 root root 668 Dec 18 15:48 ssh_host_dsa_key
-rwxr-xr-x. 1 root root 590 Dec 18 15:48 ssh_host_dsa_key.pub
-rwxr-xr-x. 1 root root 963 Dec 18 15:48 ssh_host_key
-rwxr-xr-x. 1 root root 627 Dec 18 15:48 ssh_host_key.pub
-rwxr-xr-x. 1 root root 1671 Dec 18 15:48 ssh_host_rsa_key
-rwxr-xr-x. 1 root root 382 Dec 18 15:48 ssh_host_rsa_key.pub
[root@SC-1 ssh]# chmod 700 *
[root@SC-1 ssh]# ls -l
total 156
-rwx------. 1 root root 125811 Nov 21 2013 moduli
-rwx------. 1 root root 2047 Nov 21 2013 ssh_config
-rwx------. 1 root root 3879 Nov 21 2013 sshd_config
-rwx------. 1 root root 668 Dec 18 15:48 ssh_host_dsa_key
-rwx------. 1 root root 590 Dec 18 15:48 ssh_host_dsa_key.pub
-rwx------. 1 root root 963 Dec 18 15:48 ssh_host_key
-rwx------. 1 root root 627 Dec 18 15:48 ssh_host_key.pub
-rwx------. 1 root root 1671 Dec 18 15:48 ssh_host_rsa_key
-rwx------. 1 root root 382 Dec 18 15:48 ssh_host_rsa_key.pub
[root@SC-1 ssh]#
это решило проблему.
Начать мониторинг файл журнала сервера
tail -f /var/log/auth.log
Добавьте -v, чтобы получить подробный вывод на стороне клиента
ssh user@computerB -v
Это может дать вам более подробную информацию о причине. если ключи rsa и dsa отсутствуют на сервере, исправьте их:
ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_rsa_key
ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key
Примечание: Повторная генерация ключей определенно работает.
У меня была точно такая же проблема. Мои разрешения были правильными в /etc/ssh, и эта проблема возникла из-за дублирующегося IP-адреса в сети. Как только это было исправлено, проблема исчезла.