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

Обновлено: 23.08.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-сервер ответил, но не принял ключ. Проверьте пользователя и путь к приватному ключу. Для root публичные ключи находятся в /root/.ssh/authorized_keys, а для пользователей SFTP - в /etc/ssh/authorized_keys/<user>.
REMOTE HOST IDENTIFICATION HAS CHANGED! - чаще всего это происходит после переустановки системы на сервере: IP-адрес остался прежним, а ключ сервера изменился. Удалите старую запись для этого IP из known_hosts и подключитесь заново.

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

systemctl status sshd

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

tail -f /var/log/secure

После переустановки сервера изменился SSH host key

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:Jw+5dHfqRHsTmnn2KXCXLQEaeqjoqPURNmCirPO9M+Q.
Please contact your system administrator

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

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

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

Исправление в macOS

Откройте Terminal и удалите сохраненный ключ для IP-адреса переустановленного сервера:

ssh-keygen -R SERVER_IP

Замените SERVER_IP на IP-адрес сервера. Команда удалит относящуюся к нему старую запись из файла ~/.ssh/known_hosts.

Исправление в Windows

Откройте PowerShell или Windows Terminal и выполните:

ssh-keygen.exe -R SERVER_IP

В Windows встроенный OpenSSH хранит известные ключи серверов в файле $HOME\.ssh\known_hosts. Обычно это путь C:\Users\<имя пользователя>\.ssh\known_hosts.

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

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

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

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

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

Исправление через терминал

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

chown root:root /root/.ssh /root/.ssh/authorized_keys
chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys

chown root:root /root/.ssh /root/.ssh/authorized_keys назначает пользователя root владельцем каталога и файла, а группу root - их группой.
chmod 700 /root/.ssh разрешает только владельцу читать и изменять содержимое каталога и входить в него.
chmod 600 /root/.ssh/authorized_keys разрешает только владельцу читать и изменять файл с публичными ключами.

Для пользователя SFTP ключ хранится не в домашнем каталоге, а в отдельном защищенном файле /etc/ssh/authorized_keys/siteuser. Проверьте права каталога и файла:

chown root:root /etc/ssh/authorized_keys
chmod 755 /etc/ssh/authorized_keys
chown root:root /etc/ssh/authorized_keys/siteuser
chmod 644 /etc/ssh/authorized_keys/siteuser

В этих командах siteuser нужно заменить именем нужного пользователя SFTP.

Первая команда chown назначает root:root владельцем и группой каталога /etc/ssh/authorized_keys.
chmod 755 оставляет право изменять каталог только владельцу; остальные могут просматривать его и входить в него.
Вторая команда chown назначает root:root владельцем и группой файла пользователя.
chmod 644 оставляет право изменять файл только владельцу; остальные могут его читать.

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

То же самое через Midnight Commander

Чтобы быстро перейти к ключам SFTP в Midnight Commander, нажмите Ctrl+\. В окне Directory hotlist выберите пункт Ключи SFTP – /etc/ssh/authorized_keys и нажмите Enter.

Команды chown и chmod выполнять необязательно: владельца и права можно изменить через меню Midnight Commander. Выделите нужный каталог или файл, нажмите F9 и в меню Файл выберите изменение владельца или прав доступа.

Для каталога /root/.ssh установите владельца и группу root:root, а права - 700: владелец rwx, группа ---, остальные ---.
Для файла /root/.ssh/authorized_keys установите root:root и права 600: владелец rw-, группа ---, остальные ---.
Для каталога /etc/ssh/authorized_keys установите root:root и права 755: владелец rwx, группа r-x, остальные r-x.
Войдите в этот каталог, выделите файл нужного пользователя и установите root:root и права 644: владелец rw-, группа r--, остальные r--.

Чтобы изменить права самого каталога, нужно перейти на один уровень выше и выделить каталог в панели Midnight Commander.

Когда SSH перебирает слишком много ключей

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

Received disconnect from SERVER_IP port 22:2: Too many authentication failures

Само сообщение Too many authentication failures означает, что sshd прекратил конкретную попытку подключения. На некоторых серверах дополнительная защита от перебора после нескольких таких соединений может временно заблокировать IP-адрес клиента.

Проверка с одним ключом в macOS и Linux

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

-i ~/.ssh/rish-key указывает файл нужного приватного ключа.
-o IdentitiesOnly=yes запрещает SSH использовать дополнительные ключи, которые предлагает ssh-agent. Клиент использует только явно указанные или настроенные identity-файлы.
root@server задает пользователя и адрес сервера. Вместо server укажите IP-адрес, доменное имя или имя сервера из ~/.ssh/config.

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

Та же проверка в Windows PowerShell

ssh -i "$HOME\.ssh\rish-key" -o IdentitiesOnly=yes root@server

Как увидеть, какой ключ предлагает SSH

Добавьте параметр -v, чтобы увидеть подробный процесс подключения:

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

В выводе ищите строки Offering public key: каждая такая строка показывает ключ, предложенный серверу. Посмотреть список ключей, загруженных в текущий ssh-agent, можно отдельно:

ssh-add -l

Как закрепить нужный ключ в SSH config

Чтобы не вводить параметры при каждом подключении, добавьте сервер в файл ~/.ssh/config. В Windows встроенный OpenSSH использует файл $HOME\.ssh\config:

Host rish-server
    HostName SERVER_IP
    User root
    IdentityFile ~/.ssh/rish-key
    IdentitiesOnly yes

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

ssh rish-server

Неправильный пользователь (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 и мог загружать файлы, нужно добавить его открытый ключ в файл /etc/ssh/authorized_keys/siteuser. Этот файл должен принадлежать root:root и иметь права 644, поэтому пользователь SFTP не может самостоятельно добавить или заменить ключ.

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

Выше мы уже рассмотрели этот случай. Публичные ключи пользователей SFTP хранятся в файлах вида /etc/ssh/authorized_keys/<user>. Например, для пользователя siteuser используется файл /etc/ssh/authorized_keys/siteuser. Каталог должен принадлежать root:root и иметь права 755, а файл пользователя - принадлежать root:root и иметь права 644.

Чтобы быстро открыть этот каталог в Midnight Commander, нажмите Ctrl+\. В окне Directory hotlist выберите пункт Ключи SFTP – /etc/ssh/authorized_keys и нажмите Enter. Затем откройте файл нужного пользователя.

Ключ пользователя root хранится в другом месте – /root/.ssh/authorized_keys.

Ну и всегда помните, что мы рады вам помочь в телеграм чате RISH.

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