У вас проблемы со входом на сервер?

Обновлено: 28.06.2026

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

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

Если вы или кто-то из ваших пользователей испытывает проблемы со входом на сервер – нужно понять причину. Все проблемы с безопасностью сервера (неудачные попытки входа) хранятся в AlmaLinux в одном месте – смотрите файл /var/log/secure

Также понять причину проблемы помогает команда ssh с параметром -v.

ssh -v root@server

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

Если вы пользуетесь хостингом FirstVDS, VNC-доступ открывается в панели управления серверами.

Здесь же вы можете поменять пароль, если вдруг это понадобится.

Помните, что в RISH по умолчанию предлагается запретить вход по паролю для подключения по SSH! Не путайте это с возможностью войти на сервер по локальной учетной записи. Возможность войти через локальную учетную запись сохраняется.

Что делать, если потерян SSH-ключ?

Если вы потеряли SSH-ключ и не можете подключиться к серверу через SSH, войдите на сервер через VNC и временно разрешите авторизацию по паролю. Нужный параметр находится в файле /etc/ssh/sshd_config. Отредактировать файл можно командой:

mcedit /etc/ssh/sshd_config

Нужно найти строку PasswordAuthentication и установить параметр в yes. Поиск по файлу осуществляется с помощью F7.

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

sshd -t && systemctl reload sshd.service

Команда sshd -t проверяет синтаксис конфигурации. Если проверка прошла успешно, systemctl reload sshd.service применит изменения без полного перезапуска службы. Текущую VNC-сессию лучше не закрывать, пока вы не проверили вход по SSH в новом окне терминала.

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

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

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

Быстрая диагностика по тексту ошибки

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

Connection refused - сервер доступен по сети, но на указанном порту SSH никто не принимает подключение. Проверьте, запущен ли sshd, правильный ли порт указан и не закрыт ли он firewall.
Connection timed out - клиент не может достучаться до сервера или порта. Проверьте IP-адрес, доступность сервера через VNC, правила firewall у провайдера и на самом сервере.
Permission denied (publickey) - SSH-сервер ответил, но не принял ключ. Проверьте пользователя, путь к приватному ключу, содержимое authorized_keys и права на каталог .ssh.

На сервере полезно сразу посмотреть состояние службы и последние сообщения журнала:

systemctl status sshd

journalctl -u sshd -n 100 --no-pager

tail -f /var/log/secure

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

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

В новых версиях OpenSSH проблема обычно связана не с RSA-ключами вообще, а со старым алгоритмом подписи ssh-rsa на базе SHA-1. Такой алгоритм считается устаревшим и во многих современных системах отключен по умолчанию. Поэтому старый ключ или старый SSH-клиент может перестать проходить авторизацию на AlmaLinux 9 и других современных дистрибутивах.

Современные RSA-ключи достаточной длины могут оставаться рабочими, если клиент и сервер используют современные алгоритмы подписи rsa-sha2-256 или rsa-sha2-512. Но для новых подключений проще и надежнее создавать ключ Ed25519: он короче, быстрее и хорошо поддерживается современными SSH-клиентами.

Есть три основных типа ключей, которые обычно используются для 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 root@192.168.100.61
root@192.168.100.61: 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

Если проблема на стороне сервера, проверьте права на каталог .ssh и файл authorized_keys:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Для проверки конкретного ключа с компьютера можно явно указать файл приватного ключа и запретить перебор лишних ключей из SSH-агента:

ssh -i ~/.ssh/rish-key -o IdentitiesOnly=yes root@server

Здесь /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