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

Обновлено: 15.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 ~/.ssh/rish-key -N ''

Эта команда генерирует достаточно безопасный ключ для подключения. "rish-comment" – это комментарий который поможет вам в дальнейшем отличить для чего этот ключ предназначен. Лучше всего здесь ставить имя сервера или свое имя.

Будет создано два ключа – открытый (с расширением .pub) и закрытый без расширения. Они попадут в папку .ssh пользователя, под которым команда выполняется. Для root адрес будет /root/.ssh

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

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.

Неправильный пользователь (invalid user)

Если вы подключаетесь с несуществующим пользователем (например, сделали опечатку в имени пользователя), то получите такие сообщения в лог файле /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.

Телеграм чат RISH