У меня эта повторяющаяся проблема на одном из моих MySQL кластерных серверов, на самом деле всегда происходит на любом случайном MySQL-сервере этого кластера, во многих странах, где у нас такая же конфигурация.

У меня есть этот "dbX Node", который я могу пинговать:

$ ping 192.0.2.4
PING 192.0.2.4 (192.0.2.4) 56(84) bytes of data.
64 bytes from 192.0.2.4: icmp_seq=1 ttl=61 time=1.92 ms
64 bytes from 192.0.2.4: icmp_seq=2 ttl=61 time=2.46 ms

Я могу Telnet TCP Port 22:

telnet 192.0.2.4 22
Trying 192.0.2.4 ...
Connected to 192.0.2.4.
Escape character is '^]'.

И сразу закрыли

Connection closed by foreign host.

И, очевидно, сам SSH не работает

debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type -1
debug3: Not a RSA1 key file /home/user/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: identity file /home/user/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host

Я также могу telnet к порту MySQL:

# telnet db5 3306
Trying 192.0.2.4...
Connected to db5 (192.0.2.4).
Escape character is '^]'.

Но не могу подключиться к нему:

# mysql -h db5 -uroot

Этот сервер ProLiant DL360p Gen8 работает RHEL 5.5

Когда я использую iLO для подключения и перезапуска демона SSH, у меня не появляется никаких подсказок консоли, только серая мелочь в углу ...

Мне постоянно нужно перезагрузить сервер, который сталкивается с этой проблемой.

Мне нужна помощь, чтобы решить это. Я перепробовал все. Вы когда-нибудь сталкивались с чем-то похожим на это?

2 ответа2

0

Для ssh похоже, что вы используете ключ замазки, ssh не может использовать ключ замазки, если он не экспортирован в формат openssh. похоже, что файл был отредактирован вручную, если возможно, восстановите закрытый ключ из резервной копии или попробуйте заново сгенерировать ключи, которые вы используете, или создайте новый ключ и сравните их, чтобы убедиться, что ключ, который вы используете, не имеет своего форматирования изменилось.

Что касается немедленного завершения telnet, этого следует ожидать, так как ssh ищет соединения ssh, а не соединения telnet.

После того, как вы исправите проблемы с ключами, вы сможете использовать ssh.

Что касается логина mysql, обычно логин по умолчанию для root ограничен 127.0.0.1 & local host. поэтому, если вы не разрешите определенные хосты (yourhost.domain) или% (кстати,% - плохая идея), вы не сможете подключиться, если не используете туннель ssh, чтобы вы могли подключаться локально. Другое дело, что ваша текущая команда mysql -h db5 -uroot пытается подключиться к root без пароля. Вместо этого попробуйте mysql -h db5 -u root -p , который попросит вас ввести пароль.

0

Gluzzer,

Это немного.

  1. Проверьте файлы конфигурации и убедитесь, что у вас есть доступ к устройству из сети, из которой вы подключаетесь.

  2. Убедитесь, что на этих серверах и в сетях они подключены. Что они могут пинговать тебя. Если у вас есть односторонняя маршрутизация в сети, которая потерпит неудачу при ваших попытках доступа. Некоторые сетевые администраторы блокируют запросы Ping ICMP, и правила брандмауэра / списка доступа могут препятствовать доступу к вашим устройствам, если вы не находитесь в той же подсети, что и они.

  3. Более новый сервер Linux устанавливает в iptables / ipforwarding / ipchains все заблокированные по умолчанию. Вы должны вручную открыть каждый порт или сокет, который вам нужен. Некоторые установочные скрипты позаботятся об этом. некоторые терпят неудачу, и вы должны открыть их с помощью ручных команд Linux.

Двойное лезвие меча ... заблокировано конфигами приложений / локальной машиной или вашей собственной сетевой командой.

Надеюсь это немного поможет. Приветствия ...

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .