Почему на сервер заходят по SSH-ключу, а не по паролю

Пароль можно подобрать, а SSH-ключ перебором не подбирается. Поэтому на сервер сайта заходят по ключу. С 25 по 30 октября 2026 года я посчитал неудачные входы на сервере, где стоит этот сайт: 59 103 попытки ввести пароль за шесть дней. Это около 10 000 в сутки, с 981 адреса.

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

Что такое SSH и при чём здесь ваш сайт

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

Вход защищён одним из двух способов. Либо паролем, который человек вводит каждый раз, либо парой файлов, которая и называется ключом.

Чем ключ отличается от пароля

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

	Пароль	Ключ
Как узнают чужие	перебор, утечка с другого сайта, переписка в мессенджере	только кража файла с компьютера
Что видно в журнале сервера	тысячи попыток в день	попытки без ключа сразу отклоняются
Как передать подрядчику	прислать сообщением, и он останется в переписке	подрядчик присылает только открытую часть, её не жалко показать
Как отключить одного человека	сменить общий пароль всем	удалить одну строку на сервере

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

Что показали журналы за шесть дней

Вот как выглядит одна попытка (адрес заменён на условный):

Failed password for invalid user esaweb from 203.0.113.7 port 51422 ssh2

Боты перебирают типовые логины, но не только их. Логин esaweb они попробовали 937 раз. Похоже, его взяли из адреса сайта, то есть имя домена тоже идёт в ход.

Логин	Попыток за шесть дней
ubuntu	4 512
esaweb	937
admin	908
user	639
deploy	438
test	292

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

На сервере работает fail2ban: он блокирует адрес после нескольких неудач. Это нужная вещь, но она не решает задачу целиком. Попытки шли с 981 адреса, и бот, которого заблокировали, просто продолжает с другого.

Как проверить сервер, если вы не технарь

Сначала выясните, есть ли у вас свой сервер. На обычном виртуальном хостинге сервер общий, и администрирует его хостинг. Тогда вопрос в другом: стоит ли двухфакторный вход на панель хостинга, сайт регистратора домена и админку сайта. Если у вас VPS или выделенный сервер, задайте подрядчику три вопроса.

Первый: можно ли сейчас войти на сервер по паролю? Он может показать это одной командой:

sudo sshd -T | grep -E 'passwordauthentication|permitrootlogin'

Вы хотите увидеть passwordauthentication no, а рядом permitrootlogin prohibit-password или permitrootlogin no.

Второй: у кого сейчас есть доступ? Ответ должен быть списком имён, а не словом «у нас». У каждого человека свой ключ. Ключи лежат в файле ~/.ssh/authorized_keys, и подрядчик может показать, какая строка чья.

Третий: что будет, когда вы перестанете работать вместе? Правильный ответ: вы удалите его строку, и доступ закроется. Менять ничего больше не придётся.

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

Порядок важен. Если сначала отключить пароль, а ключ не сработает, на сервер не войдёт никто, и помочь сможет только консоль хостинга.

1. Создайте ключ на своём компьютере: ssh-keygen -t ed25519. Кодовую фразу не пропускайте.
2. Добавьте открытую часть на сервер: ssh-copy-id имя@адрес-сервера.
3. Откройте второе окно и войдите по ключу. Первое окно пока не закрывайте.
4. В настройках сервера поставьте PasswordAuthentication no и PermitRootLogin prohibit-password.
5. Проверьте настройки командой sudo sshd -t, затем примените их: sudo systemctl reload ssh. На некоторых системах служба называется sshd.
6. Снова посмотрите итог через sudo sshd -T, из нового окна войдите ещё раз и только потом закройте старое.

Шаг 6 не лишний. Значение может лежать сразу в нескольких файлах: в /etc/ssh/sshd_config и в папке /etc/ssh/sshd_config.d/. На одном из наших серверов в двух файлах стояли разные значения, и действовало совсем не то, которое ожидаешь, глядя в главный файл. Поэтому верить надо итогу команды, а не файлу.

Сколько это занимает и когда этим заняться

У знающего человека настройка занимает полчаса вместе с проверкой. Лучше всего сделать это при запуске сервера. Но и на работающем сервере это безопасно, если соблюдать порядок выше: сайт на это время не останавливается.

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

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

Источники

• sshd_config: настройки сервера OpenSSH, там описаны PasswordAuthentication и PermitRootLogin.
• ssh-keygen: создание ключей.
• RFC 4252: как устроена аутентификация в SSH.
• Журнал /var/log/auth.log нашего сервера, с 25 по 30 октября 2026 года: собственный подсчёт.