Недавно столкнулся с проблемой оборудования на моем компьютере с CentOS. После замены блока питания, оперативной памяти, мобильного устройства и процессора, я думаю, проблема с оборудованием решена.
Однако я считаю, что у меня проблема с конфигурацией сети, вызывающая сбои удаленного подключения по SSH.
Я попробовал обычный ssh, используя свою исходную учетную запись и ключ, и получаю тайм-аут соединения после того, как сервер ожидает: debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
.
С самого сервера с новой учетной записью:
$ ssh -v -o PubkeyAuthentication=no chris@localhost
Last login: ...
[chris@dev ~]$
Из удаленного подключения в локальной сети, чтобы попробовать удаленный SSH:
chris::Internets|10 ~ $ ssh -v -o PubkeyAuthentication=no chris@pug
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /Users/chris/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 102: Applying options for *
debug1: Connecting to pug [192.168.1.175] port 22.
debug1: Connection established.
debug1: identity file /Users/chris/.ssh/id_rsa type 1
debug1: identity file /Users/chris/.ssh/id_rsa-cert type -1
debug1: identity file /Users/chris/.ssh/id_dsa type -1
debug1: identity file /Users/chris/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
Read from socket failed: Operation timed out
Я подтвердил, что могу:
Я видел сообщение о проблемах с разрешением DNS, вызывающих проблему, у меня UseDNS No
что должно полностью избегать DNS и не вызывать проблем.
Есть идеи здесь, поскольку я чешу в затылке, что еще искать?
Редактировать:
/ var / log / secure имеет следующее содержимое:
Nov 29 11:19:45 dev sshd[5978]: fatal: Read from socket failed: Connection reset by peer
Кроме того, я проверил, SSH прослушивает 22, как и должно быть.
[root@dev ~]# lsof -i TCP:22 | grep LISTEN
sshd 5424 root 3u IPv4 39030 0t0 TCP *:ssh (LISTEN)
sshd 5424 root 3u IPv6 39032 0t0 TCP *:ssh (LISTEN)
Чтобы избежать осложнений, я сбросил iptables:
[root@dev ~]# iptables -L -n
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
Изменился ли ключ хоста SSH из-за перенастройки? Если это так, то, возможно, файл known_hosts на стороне REMOTE не синхронизирован с новым ключом хоста и, таким образом, отклоняет соединение.
Я подозреваю, что конфигурация сети изменилась из-за изменения вашего MAC-адреса. Если вы замените материнские платы на существующей установке Linux, файл /etc/udev/rules.d/70-persistent-net.rules
создаст новые записи для ваших устройств и даст им новые имена. Итак, если у вас раньше были eth0 и eth1, теперь у вас, вероятно, будут eth2 и eth3. Вам необходимо вручную обновить этот файл после смены сетевых адаптеров.
Кроме того, можете ли вы показать свои правила брандмауэра (iptables -L -n
)?