Centos 7 зависает ssh

Обновлено: 07.07.2024

SSH, он же Secure Shell – это зашифрованный протокол, используемый для подключения к серверу и управления ним. При работе с сервером CentOS 7, вы, скорее всего, проведете большую часть времени в сеансе терминала, подключенного к серверу через SSH.

В этом мануале вы узнаете, как настроить ключи SSH на новом сервере CentOS 7.

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

1. Разрешение пользователю root заходить по SSH.

Внимание! В операционной системе CentOS 7 данная опция ВКЛЮЧЕНА уже по умолчанию и настраивать ее не нужно!

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

После нажатия Enter вводим дважды пароль.

Теперь открываем настройки SSH:

и редактируем параметр PermitRootLogin — задаем значение yes :

Перезапускаем ssh server:

или в старых версиях без systemd :

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

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

После ввода команды ssh-keygen вы увидите следующий запрос:

Нажмите Enter, чтобы сохранить пару ключей в подкаталог .ssh/ в домашнем каталоге, или укажите альтернативный путь.

После этого вы увидите:

Здесь можно ввести надежную парольную фразу, которую настоятельно рекомендуется использовать. Эта парольная фраза добавляет уровень безопасности для предотвращения входа в систему неавторизованных пользователей.

Вы увидите такой вывод:

В результате выполнения команды сгенерировалось 2 файла в каталоге

id_rsa.pub — публичный ключ;
id_rsa — секретный ключ.

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

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

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

Самый быстрый способ скопировать открытый ключ на хост – это использовать утилиту ssh-copy-id . Этот метод очень прост, потому используйте его, если у вас есть такая утилита. Если на вашем клиентском компьютере нет ssh-copy-id , вы можете использовать один из двух альтернативных методов, перечисленных в этом разделе ниже (копирование через парольную аутентификацию SSH или копирование ключа вручную).

3.1. Копирование ключа с помощью ssh-copy-id.

Инструмент ssh-copy-id включен по умолчанию во многие операционные системы, поэтому вы можете использовать его в своей локальной системе. Чтобы этот метод работал, у вас уже должен быть парольный доступ SSH к серверу.

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

Утилита использует такой синтаксис:

Вы увидите такой вывод:

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

Затем утилита сканирует локальную учетную запись, чтобы найти ключ id_rsa.pub .

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

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

/.ssh/id_rsa.pub в файл authorized_keys в домашнем каталоге

/.ssh удаленной учетной записи.

Вы увидите такой вывод:

На данный момент ваш ключ id_rsa.pub скопирован в удаленную учетную запись. Переходите к разделу 4.

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

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

Сделать это можно с помощью команды cat , которая прочитает содержимое файла открытого SSH-ключа на локальном компьютере, и конвейера, который передаст ключ через SSH-соединение.

После этого нужно убедиться, что каталог

/.ssh существует в удаленной учетной записи, а затем проверить его содержимое.

Команда выглядит так:

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

Вы можете увидеть такой вывод:

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

После этого будет предложено ввести пароль учетной записи удаленного пользователя:

После ввода пароля содержимое ключа id_rsa.pub будет скопировано в конец файла authorized_keys учетной записи удаленного пользователя. Если все получилось, переходите к разделу 4.

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

Если у вас нет парольного доступа, вам придется выполнить описанный выше процесс вручную.

Любым доступным способом подключитесь к удаленному хосту.

Если у вас есть доступ к учетной записи на удаленном сервере, убедитесь, что каталог

/.ssh существует. При необходимости создайте его.

Переходим в режим пользователя root.

Создаем служебный каталог для ключей.

Вручную нужно вставить содержимое файла id_rsa.pub в файл

/.ssh/authorized_keys на удаленной машине.

Чтобы отобразить содержимое id_rsa.pub , введите на локальной машине:

Вы увидите такой ключ:

по смыслу это будет вид

Теперь вы можете создать или изменить файл authorized_keys в этом каталоге.

Вы можете добавить содержимое файла id_rsa.pub в конец файла authorized_keys с помощью этой команды:

Если файла authorized_keys не существует, команда создаст его.

В приведенной выше команде замените public_key_string выводом команды cat

/.ssh/id_rsa.pub в вашей локальной системе. Он должен начинаться с ssh-rsa AAAA… .

Настроим права доступа на систему ключей.

Выйдем из учетной записи root:

Теперь можно проверить аутентификацию без пароля на сервере.

4. Аутентификация по SSH-ключам.

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

Если вы впервые подключаетесь к этому хосту (если вы копировали ключ вручную), вы можете увидеть такое предупреждение:

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

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

Если вы создали парольную фразу, вам будет предложено ввести ее сейчас (обратите внимание, что вводимая вами фраза не будет отображаться в терминале из соображений безопасности). После аутентификации в новом сеансе оболочки вы получите доступ к удаленному пользователю.

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

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

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

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

Убедившись, что ваша удаленная учетная запись имеет все необходимые привилегии, зайдите на свой удаленный сервер с помощью SSH-ключей (либо с правами администратора).

Затем откройте файл конфигурации демона SSH:

Внутри файла найдите директиву PasswordAuthentication . Она может быть закомментирована. Раскомментируйте строку и установите значение no .

Это отключит возможность входа в систему через SSH с использованием паролей учетных записей:

Сохраните и закройте файл. Чтобы обновить настройки, необходимо перезапустить сервис sshd:

В качестве меры предосторожности откройте новое окно терминала и проверьте работу сервиса SSH:

После того как вы подтвердите работу сервиса SSH, можете закрыть все текущие сеансы сервера.

Демон SSH теперь поддерживает только аутентификацию по SSH-ключам. Парольная аутентификация успешно отключена.

Заключение:

Теперь на вашем сервере настроена аутентификация на основе SSH-ключей, позволяющая войти в систему без пароля учетной записи.

Требования

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

Основные ошибки

Разрешение имени хоста

Большинство ошибок подключения возникает тогда, когда ссылка на хост SSH не может быть сопоставлена с сетевым адресом. Это почти всегда связано с DNS, но первопричина часто бывает не связана с DNS.

На клиенте OpenSSH эта команда:

может выдать ошибку:

В PuTTY может появиться такая ошибка:

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

Если у вас возникают проблемы с разрешением DNS на любом уровне, в качестве промежуточного решения можно использовать IP-адрес сервера, например:

Истечение времени соединения

Эта ошибка значит, что клиент попытался установить соединение с SSH-сервером, но сервер не смог ответить в течение заданного периода ожидания.

На клиенте OpenSSH следующая команда:

выдаст такую ошибку:

ssh: connect to host 111.111.111.111 port 22: Connection timed out

В PuTTY ошибка выглядит так:

Network error: Connection timed out

Убедитесь, что IP-адрес хоста указан правильно.
Убедитесь, что сеть поддерживает подключение через используемый порт SSH. Некоторые публичные сети могут блокировать порт 22 или пользовательские SSH-порты. Чтобы проверить работу порта, можно, например, попробовать подключиться к другим хостам через этот же порт. Это поможет вам определить, не связана ли проблема с самим сервером.
Проверьте правила брандмауэра. Убедитесь, что политика по умолчанию – не DROP.

Отказ в соединении

Эта ошибка означает, что запрос передается на хост SSH, но хост не может успешно принять запрос.

На клиенте OpenSSH следующая команда выдаст ошибку:

ssh user@111.111.111.111
ssh: connect to host 111.111.111.111 port 22: Connection refused

В PuTTY ошибка появится в диалоговом окне:

Network error: Connection refused

Убедиться, что IP-адрес хоста указан правильно.
Убедиться, что сеть поддерживает подключение через используемый порт SSH. Некоторые публичные сети могут блокировать порт 22 или пользовательские SSH-порты. Чтобы проверить работу порта, можно, например, попробовать подключиться к другим хостам через этот же порт.
Проверить правила брандмауэра. Убедитесь, что политика по умолчанию – не DROP, и что брандмауэр не блокирует этот порт.
Убедиться, что сервис запущен и привязан к требуемому порту.

Подводные камни

Конфигурация sshd

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

Права на ключи

chmod -v 0600 /etc/ssh/ssh_host_*_key

Она либо исправит ситуацию, либо просто ничего не сделает, а результат будет понятен из ее отчета.

localhost sshd[4503]: Authentication refused: bad ownership or modes for file /home/%user%/.ssh/authorized_keys

При этом совершенно не важно может ли sshd прочитать ключ. Лечится это понятным способом: владельцем /.ssh/authorized_keys должен быть именно тот пользователь чей это домашний каталог, а права на него должны быть не больше 0644. Есть подозрения, что это и раньше проверялось, и не новость в этой версии, но и это надо иметь ввиду, я столкнулся с этим в ходе своих экспериментов.

Сложности с PAM

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

Могу лишь сообщить, что при установке пакет удаляет /etc/pam.d/sshd и записывает на его место новый, со следующим содержимым:

localhost sshd[2111]: PAM adding faulty module: /usr/lib64/security/pam_stack.so
localhost sshd[2115]: PAM unable to dlopen(/usr/lib64/security/pam_stack.so): /usr/lib64/security/pam_stack.so: cannot open shared object file: No such file or directory

Гугл знает все, и решение нашлось, оно очень простое. Везде, где в /etc/pam.d/sshd было:
required pam_stack.so service=system-auth
должно быть:
include system-auth

И все начинает работать! Для полной ясности, /etc/pam.d/sshd должен выглядеть так:

Пользователи без пароля

localhost sshd[2073]: User %user% not allowed because account is locked

C этим тоже удалось разобраться. Оказалось, что при создании пользователя командой useradd без пароля в /etc/shadow создаются вот такого вида строки, например для пользователя test:

Лечится эта проблема одним из трех способов:

А вот и финиш!

Enjoy!

yum downgrade openssh*

И не забудьте в случае отката удалить ссылку на мой репозиторий, иначе при следующем обновлении системы последняя версия ssh опять установится сама:

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

Centos 7 зависает ssh

1. Разрешение пользователю root заходить по SSH.

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

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

4. Аутентификация по SSH-ключам.

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

Заключение:

Требования

Основные ошибки

Разрешение имени хоста

Истечение времени соединения

Отказ в соединении

Рекомендации по исправлению ошибок подключения

Брандмауэр

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

Проверка порта SSH

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

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

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

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

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

Подводные камни

Конфигурация sshd

Права на ключи

Сложности с PAM

Пользователи без пароля

А вот и финиш!

Enjoy!