Не подключается по ssh centos

Обновлено: 07.07.2024

Неправильное имя хоста

При выполнении команды подключения по SSH на стороне клиента может быть получена ошибка:

Ошибка с истечением времени соединения

Такая ошибка происходит, когда сервер SSH не может ответить подключающемуся к нему клиенту в течение определённого промежутка времени:

Для исправления этой ошибки необходимо в первую очередь сделать следующее:

проверить правильность имени и/или IP-адреса хоста сервера SSH;
проверить, что указанный порт (22) доступен для подключения. В некоторых сетях он может быть заблокирован;
проверить режим политики брандмауэра, политика которого по-умолчанию должна быть не DROP.

Отклонение соединения

Данная ошибка схожа с ошибкой истечения времени соединения и выглядит следующим образом:

Методы её устранения такие же, как и в случае, описанном в предыдущей главе, но дополнительно нужно проверить, что для подключения используется именно тот порт, который настроен на стороне сервера. Иногда, в целях безопасности его задают отличным от стандартного 22.

Настройка брандмауэра

Как известно, брандмауэры могут блокировать определённые порты и/или сетевые сервисы. Брандмауэров существует множество и в разных дистрибутивах Linux используются разные брандмауэры. Так, для Ubuntu это UFW, а для CentOS – FirewallD. Также можно использовать стандартный сервис iptables.

В зависимости от того, какой порт используется для подключения по SSH, необходимо настроить соответствующее подключение для обслуживания брандмауэром. Для начала нужно узнать, какие правила используются в данный момент. Для iptables это позволяет сделать команда:

Если политика iptables по-умолчанию DROP (или REJECT), то необходимо для правил цепочки INPUT задать разрешение для порта, используемого для SSH.
Для брандмауэра FirewallD получить список используемых правил позволяет команда:

Как видно, в списке должен присутствовать порт SSH, в данном случае 22. Он может быть и другим, в зависимости от того, что задано в настройках сервера SSH.

Проверка состояния сервера SSH

При получении ошибок подключения также не лишним будет проверить, запущен ли сам сервер SSH. Это можно сделать при помощи команды systemctl:

В случае, если демон SSH не работает, то в строке Active будет следующее:

Для запуска демона следует использовать команду:

Следует также обратить внимание на то, что обычно в дистрибутивах CentOS демон SSH называется sshd, а в Ubuntu – ssh.

Проверка порта для работы SSH

Чтобы проверить, какой порт настроен для использования сервером SSH, можно просмотреть соответствующий параметр в конфигурационном файле /etc/ssh/ssh_config . Для этого можно использовать команду grep для поиска по файлу:

Как видно из данного вывода, сервер SSH настроен на работу по стандартному порту 22. Параметр Port можно переопределять, но тогда необходимо внести изменения в соответствующие правила для брандмауэров, а также проинформировать клиентов о том, какой порт используется для подключения по SSH вместо стандартного.

Заключение

В заключение следует заметить, что в данной статье были рассмотрены лишь самые общие и распространённые неполадки, связанные с подключением по SSH. Обычно это легко выявляемые и быстро устраняемые ошибки.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Впервые запуская свой новый виртуальный сервер CentOS 8, вы должны выполнить его начальную настройку. Этот ряд процедур повысит защиту и юзабилити вашего сервера, а также обеспечит надёжную платформу для дальнейшей работы.

В этом мануале мы расскажем вам все о начальной настройке сервера CentOS 8.

1: Root-логин

Чтобы подключиться к серверу, вам понадобится его внешний IP-адрес. Кроме того, вы должны знать пароль или иметь закрытый ключ администратора – пользователя root (если вы используете аутентификацию на основе SSH-ключей).

Если вы еще не подключились к серверу, сделайте это сейчас. Чтобы войти на сервер как пользователь root, введите эту команду:

После запуска этой команды может появиться предупреждение о подлинности хоста; примите его и введите учётные данные root. Если ваши SSH-ключи защищены парольной фразой, вам нужно будет ввести и эту фразу. При первом подключении к серверу система предложит изменить root-пароль.

Что такое root?

Пользователь root – это администратор среды Linux, который обладает максимальными привилегиями. Именно поэтому выполнять рутинную работу через аккаунт root крайне небезопасно – так вы можете случайно нанести системе непоправимый ущерб.

Потому для постоянной работы в среде Linux принято использовать специальный аккаунт с расширенными привилегиями, с доступом к команде sudo, о чем речь пойдет далее в этом мануале.

2: Создание нового пользователя

Войдя в систему как root, создайте нового пользователя для постоянной работы с сервером.

Чтобы создать нового пользователя по имени 8host, введите:

Примечание: Замените условное имя 8host именем своего пользователя.

Затем вам нужно установить надежный пароль для вашего нового пользователя:

Команда предложит дважды ввести пароль. Сейчас этот аккаунт уже можно использовать, но пока что у него нет доступа к sudo. Давайте предоставим ему такой доступ.

3: Доступ к sudo

Итак, теперь у вас есть новый пользователь с обычными привилегиями. Однако для управления сервером таких прав не достаточно.

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

В CentOS 8 доступ к этой команде по умолчанию есть у всех, кто входит в группу wheel. Чтобы добавить вашего нового пользователя в эту группу, запустите следующую команду в сессии пользователя root:

usermod -aG wheel 8host

Теперь новый пользователь имеет права суперпользователя и может выполнять задачи администратора.

4: Настройка брандмауэра

Серверы CentOS могут использовать брандмауэр для блокировки соединений с отдельными сервисами. Как правило, обычно в качестве брандмауэра на CentOS используется firewalld. Инструмент firewall-cmd позволяет установить политики брандмауэра и настроить исключения.

Сначала установите брандмауэр firewalld.

dnf install firewalld -y

По умолчанию firewalld поддерживает соединения ssh, потому брандмауэр можно включить сразу после установки, не боясь заблокировать себя на своем же сервере:

systemctl start firewalld

Теперь проверьте состояние брандмауэра:

systemctl status firewalld
firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2020-02-06 16:39:40 UTC; 3s ago
Docs: man:firewalld(1)
Main PID: 13180 (firewalld)
Tasks: 2 (limit: 5059)
Memory: 22.4M
CGroup: /system.slice/firewalld.service
└─13180 /usr/libexec/platform-python -s /usr/sbin/firewalld --nofork --nopid

Если вы видите active и enabled, вы можете быть уверены, что брандмауэр автоматически запустится при перезапуске сервера.

Теперь, когда сервис установлен и запущен, мы можем использовать утилиту firewall-cmd, чтобы настроить политику брандмауэра.

Для начала давайте узнаем, какие сервисы поддерживаются брандмауэром:

firewall-cmd --permanent --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: eth0 eth1
sources:
services: cockpit dhcpv6-client ssh
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:

Чтобы увидеть дополнительные сервисы, которые вы можете включить по имени, введите:

Помните, что вам нужно явно открыть в брандмауэре все необходимые вам порты.

5: Проверка доступа к новому пользователю

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

Примечание: Пока вы не убедитесь, что можете войти в систему и использовать sudo в сессии нового пользователя, рекомендуем оставаться в системе как пользователь root. Если у вас возникнут проблемы, вы сможете устранить неполадки и внести необходимые изменения с правами root.

Настройка SSH-доступа для вашего нового пользователя зависит от того, что использует ваша учетная запись root для аутентификации – пароль или SSH-ключи.

Парольная аутентификация

Если вы вошли в свою учетную запись root с помощью пароля, значит, SSH поддерживает парольную аутентификацию. Вы можете подключиться по SSH к новому пользователю, открыв новую сессию терминала и используя SSH с именем нового пользователя:

Введите пароль пользователя, после чего вы войдете в систему. Помните, что если вам нужно запустить команду с правами администратора, нужно для этого добавить sudo:

При первом запуске sudo в каждой сессии (и периодически при запуске разных команд) вам будет предложено ввести пароль текущего пользователя.

Чтобы повысить безопасность сервера, вместо парольной аутентификации мы настоятельно рекомендуем настроить SSH-ключи. Следуйте инструкциям в мануале Установка SSH-ключей в CentOS 8.

Аутентификация на основе SSH-ключей

Если вы вошли в учетную запись root через SSH-ключи, парольная аутентификация отключена. Вам нужно добавить копию открытого ключа в файл

/.ssh/authorized_keys нового пользователя для дальнейшего доступа к системе.

Поскольку открытый ключ уже находится на сервере в файле пользователя root,

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

Проще всего это сделать с помощью команды rsync. Она скопирует каталог .ssh, сохраняя все права доступа к нему. Вместо 8host вы должны указать имя вашего пользователя.

Примечание: Команда rsync обрабатывает исходные и целевые места, имя которых заканчивается косой чертой, иначе, чем те, у которых в имени нет косой черты. При использовании rsync убедитесь, что в качестве исходного каталога вы используете

Если вы случайно добавите косую черту в команду, rsync вместо структуры каталога

/.ssh скопирует содержимое каталога

/.ssh корневой учетной записи в домашний каталог пользователя sudo. Файлы будут в неправильном месте, и SSH не сможет их найти.

rsync --archive --chown=8host:8host

Теперь вернитесь в терминал на локальной машине и создайте новое SSH соединение:

Вы должны без пароля войти в новую учетную запись пользователя. Помните, чтобы запустить команду с правами администратора, нужно ввести перед ней sudo:

Заключение

Вы выполнили начальную настройку сервера, и теперь он готов к установке нового программного обеспечения и к разработке проектов. Настроив основные компоненты серверной среды, вы можете оптимизировать работу системы: настроить справку, текстовый редактор по умолчанию и т. п.

В данном руководстве вы узнаете, что делать, если сбрасываются клиентские соединения, клиент жалуется на шифрование или возникают проблемы с неизвестным или измененным удаленным хостом.

После успешного подключения протокол SSH согласовывает зашифрованное соединение с клиентом на основе установления доверия. Есть несколько уникальных проблем, которые могут возникнуть на этом этапе. В этом мануале рассматриваются способы их определения, устранения и предотвращения.

Требования

Убедитесь, что можете подключиться к виртуальному серверу через консоль.
Проверьте панель на предмет текущих проблем, влияющих на работу и состояние сервера и гипервизора.

Общие ошибки

Ошибка при проверке ключа хоста

Когда к серверу подключается SSH-клиент, сервер пытается идентифицировать себя с помощью ключа хоста. Если главный ключ изменился, вы можете увидеть такое предупреждение:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
.
В PuTTY предупреждение выглядит так:
WARNING - POTENTIAL SECURITY BREACH!
The server's host key does not match the one PuTTY has
cached in the registry. This means that either the
Server administrator has changed the host key, or you
.

Обычно причиной этой ошибки является:

Восстановление сервера с помощью снапшота или резервной копии.
Перенос плавающего IP на другой сервер.
Переустановка SSH-сервера с помощью менеджера пакетов

Чтобы решить эту проблему, вы можете очистить ключи хоста.

Соединение закрыто или сброшено

Иногда соединения устанавливаются на уровне сокета, но сбрасываются во время проверки ключей хоста. В PuTTY эта ошибка выглядит так:

Server Unexpectedly closed network connection

Клиент OpenSSH выдаёт такую ошибку:

Connection closed by 111.111.111.111 port 22

Эта ошибка, как правило, происходит по следующим причинам:

Сбой или ошибки сервиса SSH.
Сервис SSH не может инициализировать подключение из-за отсутствия ключей хоста сервера.

В таком случае необходим более тщательный анализ выходных данных протокола. В большинстве случаев данные нужно исследовать через веб-консоль и убедиться, что сервис в данный момент запущен и связан с требуемым портом.

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

Ошибки переговоров с хостом

При инициировании протокола SSH генерируется общий секретный ключ. Это делается посредством шифрования, согласованного между клиентом и хостом. Если на данном этапе возникает несоответствие, переговоры срываются, и вы можете увидеть такие ошибки в PuTTY:

Клиент OpenSSH сообщит:

Unable to negotiate with 111.111.111.111: no matching key exchange method found.
Their offer: diffie-hellman-group1-sha1

Источником этой ошибки может быть:

Несовпадение реализаций клиента и хоста (если вы используете современный клиент OpenSSH и устаревший хост, последний может просто не поддерживать шифрования клиента).
Изменение списка шифрования клиента SSH (возможно, сервер его не поддерживает).

Чтобы решить эту проблему, вам необходимо правильно настроить шифрование на SSH-клиенте.

Устранение неполадок

Сброс ключей известных хостов

Ключи хоста обычно хранятся в файле

/.ssh/known_hosts клиента OpenSSH. PuTTY обычно хранит их в реестре Windows (HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys).

В PuTTY можно использовать диалоговое окно, чтобы разрешить подключение и обновить реестр (просто выберите Yes). Кроме того, вы можете удалить запись вручную.

На клиенте OpenSSH вы можете найти записи хоста в файле

/.ssh/known_hosts и удалить их вручную. Также можно использовать команду ssh-keygen.

ssh-keygen -R your_server_ip

Команда попытается получить доступ и очистить соответствующую запись хоста в файле known_hosts:

После этого попробуйте снова подключиться к серверу.

Проверка и генерирование SSH-ключей

Если у хоста SSH нет собственного закрытого ключа и он не может сгенерировать общий секретный ключ, соединение будет сброшено. Откройте каталог /etc/ssh и попробуйте найти в нём группу файлов с именами sshd_host_*_key. Среди них должен быть файлы с расширением .pub.

Если таких файлов нет, сгенерируйте их с помощью команды ssh-keygen.

Команда выведет сгенерированные ключи:

ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519

Теперь попробуйте снова подключиться к серверу.

Настройка поддерживаемых шифров SSH

Вы можете настроить поддерживаемые SSH-шифры на клиентской машине, если нужна поддержка устаревшего шифрования (например, SHA1). Это не очень распространенная проблема; обычно она случается, если вы используете новый клиент SSH для подключения к устаревшему SSH-серверу, и они поддерживают разные шифры.

В OpenSSH поддержку SHA1 можно настроить с помощью опции KexAlgorithms. Введите в командную строку:

openssh -oKexAlgorithms=+diffie-hellman-group1-sha1 root@your_server_ip

Клиент PuTTY должен поддерживать группу Диффи-Хеллмана (Connection → SSH → Kex).

Процесс конфигурации индивидуален для каждого системного администратора, но все же имеется несколько пунктов, полезных для всех юзеров. В рамках данной статьи мы поговорим не только о серверной составляющей, но и о клиентской, а также укажем, на каком из устройств выполняется определенное действие.

Установка компонентов и запуск сервера

Мы уже сказали, что SSH по умолчанию добавлен в список системных библиотек CentOS 7, но иногда по некоторым причинам необходимые компоненты отсутствуют на компьютере. В таком случае их потребуется добавить, а затем активировать работу сервера.

После успешного произведения указанных выше инструкций можно смело переходить к началу конфигурации. Хотим обратить ваше внимание, что обязательно следует читать показанные на экране уведомления во время активации команд. Они могут свидетельствовать о возникновении определенных ошибок. Своевременное исправление всех неполадок поможет избежать дальнейших проблем.

Редактирование конфигурационного файла

Конечно, конфигурационный файл редактируется только на усмотрение системного администратора. Однако мы хотим показать, как его запустить в текстовом редакторе и на какие пункты следует сделать акцент в первую очередь.

nano

Создание пары RSA-ключей

Криптографический алгоритм RSA (аббревиатура от фамилий Rivest, Shamir и Adleman) используется сервисом SSH для создания пары ключей. Такое действие позволить максимально обезопасить клиентскую и серверную часть при проведении соединений. Задействовать придется обе цепи, чтобы создать пару ключей.

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

Копирование открытого ключа на сервер

Как уже было сказано выше, копирование ключа необходимо для дальнейшей безпарольной аутентификации. Сделать такое действие можно одним из трех способов, каждый из которых будет наиболее оптимальным в определенных ситуациях. Давайте рассмотрим все их по порядку.

Утилита ssh-copy-id

The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)?

Оно обозначает, что сервер не находится в списке надежных источников и будет задан вопрос, стоит ли проводить дальнейшее подключение. Выберите вариант yes .

Осталось только ввести пароль от учетной записи сервера, и на этом процедура копирования через упомянутую утилиту будет успешно завершена.

Копирование открытого ключа по SSH

При отсутствии утилиты ssh-copy-id рекомендуем задействовать стандартные возможности инструмента SSH, если, конечно, у вас имеется доступ к серверной учетной записи. Выгрузка ключей производится посредством обычного подключения, а именно:

cat

/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p

Ручное копирование открытого ключа

Иногда случаются ситуации, когда невозможно использовать утилиту ssh-copy-id, а также отсутствует доступ по паролю. Тогда копирование осуществляется вручную.

cat

На этом процедура копирования ключа успешно завершена. Благодаря этому теперь доступна аутентификация к серверу путем ввода ssh username@remote_host . Однако подключиться можно и через пароль, что понижает безопасность такой сети.

Отключение аутентификации по паролю

Отключение возможности входа по паролю, в обход ключа, делает такое удаленное соединение менее защищенным. Поэтому рекомендуется деактивировать эту функцию для предотвращения несанкционированной аутентификации со стороны злоумышленников.

На этом статья, в которой вы были ознакомлены с основными конфигурационными моментами протокола SSH, подходит к концу. Настоятельно рекомендуем изучить содержимое выдачи после активации команд, поскольку там иногда содержатся описания ошибок. Их решение ищите в официальной документации инструмента или дистрибутива CentOS.

Мы рады, что смогли помочь Вам в решении проблемы.

Отблагодарите автора, поделитесь статьей в социальных сетях.

Опишите, что у вас не получилось. Наши специалисты постараются ответить максимально быстро.

Читайте также: