ИТ Блог. Администрирование серверов на основе ядра Linux
Разработчики сетевых протоколов, ИТ-специалисты и сетевые администраторы используют SSH для удаленного доступа к компьютерам. Он гарантирует безопасную зашифрованную связь по незащищенным сетям. Однако, хотя установка соединения между двумя машинами обычно происходит после настройки как серверной, так и клиентской стороны, иногда это не так.
Время от времени вы будете сталкиваться с проблемами при попытках подключения SSH к вашей системе. Такие явления расстраивают. Как и ожидалось, самый актуальный вопрос пользователей Linux — почему они не могут использовать SSH на своих серверах.
Эта статья отвечает на предыдущий вопрос. Более того, помимо объяснения причин, по которым вы можете столкнуться с ошибками подключения при использовании SSH, в этой статье также будут изложены возможные решения для каждой причины, по которой вы можете столкнуться с ошибкой подключения.
Устранение неполадок SSH не является сложным процессом. Однако мы не можем также назвать это предприятие слишком сложным. Все, что вам нужно, это достаточно информации для решения каждой проблемы, когда она возникает.
Ниже приведены некоторые из причин распространенных ошибок подключения SSH в Linux и возможные решения:
Компьютеры Linux поставляются с брандмауэром UFW. Возможно, вам потребуется сбросить настройки брандмауэра UFW, чтобы разрешить установку и настройку SSH. Однако многие люди предпочитают применять строгие политики брандмауэра в своих сетях в целях безопасности. В таких случаях только определенные IP-адреса могут использовать SSH для ваших серверов.
При сбое подключения в результате настройки брандмауэра будет возвращено сообщение, подобное следующему:
andreyex@laptop:/# ssh root@andreyex.ru ssh: connect to host andreyex.ru port 22: Connection refused # Подтвердите с помощью telnet. Обычно он подключается за считанные секунды andreyex@laptop:/#telnet andreyex.ru Trying 192. 168.101.01…
Вы можете проверить свою систему, чтобы узнать, блокируют ли соединение проблемы с брандмауэром. Кроме того, эта проблема может быть результатом проблемы с портом. Убедитесь, что ваша система настроена на порт 22, используя следующую команду:
grep Part/etc/ssh/sshd_canfig
Предыдущая команда должна предоставить вам номер порта. Убедитесь, что это порт 22. Если это не порт 22, перейдите к устранению неисправности. Двойная проверка DNS-имени или IP-адреса, если проблема не устранена, поможет решить эту проблему с SSH-подключением.
Изначально все использовали SSH по паролю. Однако это уже не так, особенно с учетом того, что SSH по паролю чрезвычайно опасен и небезопасен. Таким образом, многие люди сейчас используют SSH по ключевому файлу. Этот метод иногда вызывает несколько проблем.
Процесс инициации SSH-подключения с помощью файла ключа включает в себя следующее:
Вы должны иметь возможность использовать SSH после завершения процесса. Однако часто возникает следующая проблема:
andreyex@laptop:/# ssh root@andreyex.ru Permission denied (publickey).
Примечательно, что предыдущее сообщение об ошибке имеет две причины. Во-первых, это может быть результатом неправильного сопряжения локального открытого SSH и закрытого ключей. Система, несомненно, отклонит использование закрытого ключа.
Во-вторых, проблема может возникнуть из-за отсутствия права входа в систему для закрытого ключа. Это условие возникает из-за неправильного входа в систему открытого ключа или отсутствия открытого ключа. Сообщите своему менеджеру сервера, чтобы он внес необходимые изменения.
Одним из обязательных условий безопасности, которые вы обнаружите при использовании SSH, является его способность контролировать открытие вашего файла ключа SSH. Ключевой файл не открывается широко для самозащиты. Таким образом, у вас должен быть файловый режим 0400 или 0600. Любое обратное вызовет ошибку подключения, подобную следующей:
andreyex@laptop:/# ssh -i id_rsa root@andreyex.ru @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ WARNING: UNPROTECTED PRIVATE KEY FILE! @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0644 for 'id_rsa' are too open. It is required that your private key files are NOTaccessible by others. This private key will be ignored. bad permissions: ignore key: id_rsa Permission denied (publickey).
Вы можете использовать флаг –v для подробного вывода в следующей команде, чтобы исправить эту аномалию:
ssh -v $user@$server_ip
Следующее изображение может в равной степени сбивать с толку и пугать:
andreyex@laptop:/# ssh root@andreyex.ru WARNING: POSSIBLE DNS SPOOFING DETECTEDI The ECDSA host key for [andreyex.ru]:22 has changed, and the key for the corresponding TP address [192.168.101.01]: 22 is unknown. This could either mean that DNS SPOOFING is happening or the IP address for the host and its host key have changed at the same time. WARNING. REMOTE HOST IDENTIFICATION HAS CHANGEDI IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is37:df:b3:of:54:03:57:05:aa:32:65-fcco8.e7:f9.3a. Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /root/.ssh/known_hosts:2 remove with: ssh-keygen -f "/root/ssh/known_hosts" -R [andreyex.ru]:22 ECDSA host key for [andreyex.ru]: 22 has changed and you have requested strict checking. Host key verification failed.
Иногда у каждого SSH-сервера есть отпечаток пальца. Однако отпечаток будет автоматически отличаться, если вы используете повторно подготовленный сервер или другой. Ваш компьютер всегда будет сохранять отпечаток пальца сервера при первом входе в систему, чтобы его можно было сравнивать каждый раз, когда вы входите в систему. Предыдущее предупреждение появляется каждый раз, когда отпечатки пальцев не совпадают.
Вы можете проигнорировать предупреждение и перейти к SSH, если ваш сервер недавно был повторно инициализирован. Очистите файл или удалите запись из каталога ~/.ssh/known_hosts.
Как и любой другой протокол управления сервером, SSH часто сталкивается с проблемами. Ранее упомянутые являются одними из наиболее распространенных проблем, с которыми вы можете столкнуться. Хотя эти проблемы невероятно неприятны, для них всегда есть решения. Надеюсь, предыдущие иллюстрации помогут вам сориентироваться в них.
(Пока оценок нет)
Загрузка...
