Skip to main content

Проблемы со входом на сервер

Обновлено: 02.10.2023
проблемы со входом на сервер

Первоначальная диагностика

Если вы или кто-то из ваших пользователей испытывает проблемы со входом на сервер – нужно понять причину. Все проблемы с безопасностью сервера (неудачные попытки входа) хранятся в AlmaLinux в одном месте – смотрите файл /var/log/secure
Так же понять проблемы при подключении помогает команда ssh с параметром -v.
ssh -v root@server
Если вы сами не можете войти на сервер – помните – у вас есть возможность войти посредством логина и пароля на локальный терминал вашего сервера. Обычно это осуществляется через VNC протокол. То, что вы сделаете таким образом – это как-будто вы подключили свою клавиатуру и монитор непосредственно к вашему серверу. Это не имеет отношения к SSH подключению, которое вы делаете обычно через терминал.
Если вы пользуетесь хостингом FirstVDS, то это делается в панеле управления серверами.
Здесь же вы можете поменять пароль, если вдруг это понадобится.
Помните, что в RISH по умолчанию предлагается запретить вход по паролю для подключения по SSH! Не путайте это с возможностью войти на сервер по локальной учетной записи. Возможность войти через локальную учетную запись сохраняется.

Что делать при потере ключа? ( Разрешение авторизации по паролю при подключении по SSH)

Если вы потеряли ключ SSH и не можете подключиться к серверу через SSH, вам понадобится временно разрешить авторизацию по паролю при подключении по VNC. Параметр для разрешения авторизации по паролю находится в файле /etc/ssh/sshd_config. Отредактировать файл можно командой:
mcedit /etc/ssh/sshd_config
Нужно найти строку PasswordAuthentication и установить параметр в yes. Поиск по файлу осуществляется с помощью F7.
После изменения параметра обязательно надо перезапустить сервис sshd.
systemctl restart sshd.service
Теперь можете пытаться заново подключиться по SSH с помощью пароля и добавить новый ключ.
После добавления ключа не забудьте отключить авторизацию по паролю снова!

Какие проблемы приводят к невозможности подключения к серверу?

Неверный алгоритм, выбранный для генерации ключа

Давайте посмотрим на те сообщения, которые видны в лог файле /var/log/secure
sshd[1221391]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
sshd[1221391]: Received disconnect from 82.140.246.18 port 50871:11: Shutdown [preauth]
sshd[1221391]: Disconnected from authenticating user root 82.140.246.18 port 50871 [preauth]
Тип ключа 'ssh-rsa' не входит в список поддерживаемых алгоритмов для публичных ключей ('PubkeyAcceptedAlgorithms'). Выбранный тип ключа не допускается для использования.
Ключевое слово "key type ssh-rsa not in PubkeyAcceptedAlgorithms". Выбранный тип ключа запрещен для публично принимаемых алгоритмов.
В целях улучшения безопасности, некоторые дистрибутивы, включая AlmaLinux 9, стали отказываться от поддержки более старых и потенциально менее безопасных методов аутентификации, таких как ключи RSA с малой длиной. Это сделано для поощрения использования более новых и безопасных методов, таких как Ed25519.
Причина, по которой RSA ключи не рекомендуются, заключается в том, что они требуют большей длины ключа для достижения такого же уровня безопасности, что и ключи на основе эллиптических кривых (ECDSA и Ed25519). Это делает их менее эффективными с точки зрения производительности. Кроме того, RSA потенциально подвержен определенным видам атак, особенно если используются ключи меньшей длины.
Есть три основных типа ключей, которые обычно используются для SSH:
  • RSA – это наиболее распространенный и поддерживаемый тип ключа. Он работает на основе факторизации больших целых чисел. RSA ключи допускают использование различных длин (обычно от 1024 до 4096 бит), но даже при использовании 2048-битных или 4096-битных ключей, они могут быть более медленными и менее безопасными, чем ECDSA или Ed25519 ключи. Рекомендуется использовать 4096-битные ключи.
  • ECDSA (Elliptic Curve Digital Signature Algorithm) – это ключи на основе эллиптических кривых, которые обеспечивают тот же уровень безопасности, что и RSA ключи, но с использованием более коротких ключей, что делает их более быстрыми и эффективными. Однако, ECDSA имеет некоторые известные проблемы с безопасностью, если не обеспечивается должная случайность при генерации ключей.
  • Ed25519 – это еще один тип ключей на основе эллиптических кривых, который был специально разработан для устранения многих проблем, связанных с другими типами ключей. Они предлагают высокую производительность, хороший уровень безопасности и решают проблемы с случайностью, которые могут встречаться с ECDSA.
На сегодняшний день, Ed25519 является наиболее рекомендуемым типом ключей для использования. Они обеспечивают хороший уровень безопасности и производительности, и устойчивы к большинству известных атак.
Команда для генерации ключа нужного типа:
ssh-keygen -t ed25519 -C "rish-comment" -f "/root/.ssh/rish-key" -N ''
Эта команда генерирует достаточно безопасный ключ для подключения. "rish-comment" – это комментарий который поможет вам в дальнейшем отличить для чего этот ключ предназначен. Лучше всего здесь ставить имя сервера или свое имя.

Попытка войти по паролю, если такой тип аутентификации запрещен

ssh Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в вашем браузере должен быть включен Javascript.
Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в вашем браузере должен быть включен Javascript.: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
Это свидетельствует о том, что метод авторизации не подходит. Способы авторизации указаны в скобках.
Вообще можно получить больше подробной информации во время подключения, если попытаться подключиться к серверу с параметром -v, как об этом было написано в самом начале.
ssh -v root@server

Файл с вашим приватным ключом имеет слишком широкие права доступа

Если файл с вашим приватным ключом имеет слишком широкие права доступа, SSH клиент обычно выдаст предупреждение или ошибку, которая будет выглядеть примерно так:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/username/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/home/username/.ssh/id_rsa": bad permissions
Permission denied (publickey).
Файл с вашим приватным ключом должен иметь права доступа 600. То есть быть доступным только владельцу. Чтобы исправить это, вы можете изменить права доступа к файлу так, чтобы только владелец мог читать и записывать этот файл, используя следующую команду:
chmod 600 /path/to/your/private/key
Здесь /path/to/your/private/key - это путь к файлу с вашим приватным ключом. Это обычно ~/.ssh/id_rsa для RSA ключей или ~/.ssh/id_ed25519 для ключей Ed25519.

Неправильный пользователь

Если вы подключаетесь с несуществующим пользователем (например, сделали опечатку в имени пользователя), то получите такие сообщения в лог файле /var/log/secure.
sshd[1654]: Invalid user test from 192.168.100.145 port 54320
sshd[1654]: pam_unix(sshd:auth): check pass; user unknown
sshd[1654]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.100.145
sshd[1654]: Failed password for invalid user test from 192.168.100.145 port 54320 ssh2
Помимо очевидного случая, может быть еще неочевидный. Например, вы добавили открытый ключ пользователю root, а подключиться пытаетесь к созданному пользователю для доступа к SFTP на сервере с именем siteuser (к примеру).
Всегда помните об этом нюансе и если вы хотите чтобы пользователь siteuser подключился по SFTP к серверу и смог закачивать файлы, нужно добавить его открытый ключ по адресу /home/siteuser/.ssh/authorized_keys

Вы не добавили открытый ключ пользователя или добавили не тому

Выше мы уже рассмотрели этот случай. Помните, что ключи пользователей для доступа по SFTP хранятся по адресам /home/siteuser/.ssh/authorized_keys. Где siteuser – это имя вашего пользователя.
Ключ пользователя root хранится в другом месте – /root/.ssh/authorized_keys.
Ну и всегда помните, что мы рады вам помочь в телеграм чате RISH.