rizloff
Linux

SSH без пароля или аутентификация с использованием шифрованных ключей

4 мин чтения17 комментариевПеречитано в 2026

У вас есть отдельно стоящий сервер? Ходите на него через ssh? Пароль в целях безопасности больше 10 символов? В день заходите на сервер n-ное количество раз? Реально задолбало вводить каждый раз пароль на вход? Меня тоже
А выход как всегда прост до безобразия, потому что все уже придумано до нас.

Ключи SSH. Или метод Identity/Pubkey

При использовании метода идентификации Identity/Pubkey исключается использования статических паролей. Дабы каждый раз не набирать пароли, которые можно перехватить кейлоггером ну или просто подсмотреть, мы будем хранить на диске пару ключей, которые и будут использоваться для проверки подлинности. Вот некоторые из положительных моментов этого типа аутентификации:

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

Генерация SSH ключей. Или создание Identity/Pubkey

Для генерации пары ключей нам необходимо воспользоваться утилитой ssh-keygen.

ssh-keygen -t rsa
ssh-keygen -t ed25519

Опцией -t rsa мы указали тип создаваемых ключей (возможны варианты ключей — rsa1, rsa или dsa⁠1)

Настройка сервера SSH

Все вышеуказанные манипуляции мы делали на локальной машине, теперь надо поднастроить удаленную (сервер куда мы будем логиниться). Ключи есть, теперь необходимо разрешить данный тип аутентификации на сервере SSH. Сначала определим тип аутентификации — Pubkey или Identity, установив следующие настройки в sshd_config

# Should we allow Identity (SSH version 1) authentication?
RSAAuthentication yes

# Should we allow Pubkey (SSH version 2) authentication?
PubkeyAuthentication yes

# Where do we look for authorized public keys?
# If it doesn't start with a slash, then it is
# relative to the user's home directory AuthorizedKeysFile
.ssh/authorized_keys

Приведенные выше значения разрешают аутентификацию Identity/Pubkey для протокола SSH версии 1 и 2⁠2, и проверяют наличие публичных ключей в файле $HOME/.ssh/authorized_keys. Необходимо проверить наличие этих строк в файле конфигурации /etc/ssh/sshd_config, если таковых нету — добавить и перезапустить сервис.

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

Два варианта

ssh-copy-id

Скорей всего у вас должна быть утилитка ssh-copy-id и с ее помощью

ssh-copy-id -i ~/.ssh/id_rsa.pub youruser@remote.server.host
ssh-copy-id -i ~/.ssh/id_ed25519.pub youruser@remote.server.host

«ручной» вариант

cat ~/.ssh/id_rsa.pub | ssh -l user@remote.server.host 'mkdir -p .ssh;touch .ssh/authorized_keys; cat >> .ssh/authorized_keys;chmod 700 ~/.ssh;chmod 600 ~/.ssh/authorized_keys'

или такой

# на локальном хосте
~/.ssh/id_rsa.pub youruser@remote.server.host
ssh youruser@remote.server.host

# на удаленном хосте
[ -d ~/.ssh ] || (mkdir ~/.ssh; chmod 700 ~/.ssh)
cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Вроде все сделали, все настроили — пора пробовать

ssh your_user@remote.server.host

Должно пустить без пароля (если только вы не ставили пароль на сам ключ). upd: по совету Vladimir-а (см. первый комментарий), ставим более правильные права доступа (chmod) — на каталог ~/.ssh ставим 700

Что-то не сработало или нашли ошибку — напишите: rizloff@gmail.com или @rizloff в Telegram.

17 комментариев

2026Ответил: разные ключи к одному серверу · всё равно спрашивает пароль · нужен ли authorized_keys2 · как быть с Windows

  1. Vladimir

    К ручному методу я бы добавил изменение прав на каталог (0700) и ключ (0600). Так безопаснее :-)

  2. Vladimir

    Мда, сорри, не увидел второй блок :-( Но всё равно права на папку ~/.ssh лучше ставить 0700 — ибо смысл туда ходить посторонним, если всё равно на чтение ключей прав у них быть не должно?

  3. rizloffавтор

    Спасибо за совет, подкорректировал права доступа
    И за плагин спасибо - разобрался, все работает.

  4. user

    В статье ошибка, нужно заменить:

    ssh-copy-id -i ~/.ssh/id_rsa youruser@remote.server.host
    на
    ssh-copy-id -i ~/.ssh/id_rsa.pub youruser@remote.server.host

    cat ~/.ssh/id_rsa | ssh -l user@remote.server.host 'mkdir -p .ssh;touch .ssh/authorized_keys; cat >> .ssh/authorized_keys;chmod 700 ~/.ssh;chmod 600 ~/.ssh/authorized_keys'
    на
    cat ~/.ssh/id_rsa.pub | ssh -l user@remote.server.host 'mkdir -p .ssh;touch .ssh/authorized_keys; cat >> .ssh/authorized_keys;chmod 700 ~/.ssh;chmod 600 ~/.ssh/authorized_keys'

    rizloffавтор

    Таки да, вы правы
    А ведь столько раз пересматривал запись и столько же раз делал по своей же инструкции и не заметил.
    Спасибо большое, подправил

  5. Peering

    А как быть если к одному серверу нужно подключиться с разными authorized_keys как прописать в конфиге,,,

    rizloff

    На сервере каждый открытый ключ дописывается отдельной строкой в authorized_keys того пользователя, под которым входят. А на своей машине удобно завести в ~/.ssh/config по записи на каждый ключ:

    Host work
    HostName server.example.org
    User deploy
    IdentityFile ~/.ssh/id_work
    IdentitiesOnly yes

    Дальше просто ssh work. IdentitiesOnly yes не даёт ssh перебирать все ключи подряд: когда ключей много, сервер рвёт соединение раньше, чем дойдёт очередь до нужного.

  6. Рома

    Все равно запрашивает пароль на удаленного юзера!

  7. Николай

    > А как быть если к одному серверу нужно подключиться с разными authorized_keys как прописать в конфиге,,,
    Добавлять каждый ключик новой строчкой в ~/.ssh/authorized_keys

    > Все равно запрашивает пароль на удаленного юзера!
    Значит что-то не так делали. Инструкция рабочая.

  8. сымбат

    у меня также запрашивает пароль но без пароля и даже с вводом пароля не пускает. Как исправить?

    rizloff

    Сначала смотрим, что происходит: ssh -v user@host покажет, предлагался ли ключ и что ответил сервер. Если ключ предлагался, но сервер его не принял, почти всегда виноваты права на сервере. Каталог ~/.ssh должен быть 700, файл authorized_keys 600, оба должны принадлежать самому пользователю (chown -R user:user ~/.ssh), а домашний каталог не должен быть доступен на запись группе. Точную причину сервер пишет в журнал: journalctl -u sshd в Fedora или journalctl -u ssh в Ubuntu.

  9. Степан

    "Значит что-то не так делали. Инструкция рабочая."
    ну да, да....

    автор
    а если версия ssh2 не нужно ли создавать authorized_keys2 ?
    а править конфиг файл не нужно?

    rizloff

    Не нужно. authorized_keys2 устарел ещё в OpenSSH 3.0: ключи для второй версии протокола лежат в обычном authorized_keys. Конфиг сервера тоже трогать не надо — вход по ключу включён по умолчанию.

  10. Александр

    Все эти действия проводятся на удалённой тачке. Разве этого достаточно?? А на локальной, если она под управлением linux? Или windows? В случае с виндой надо ещё с PUTTY.EXE колдовать.

    rizloff

    Ключи создаются на своей машине, на сервер уходит только открытый ключ — об этом первая половина записи. В Windows 10 и 11 OpenSSH уже встроен: ssh-keygen и ssh работают в PowerShell, PuTTY не обязателен.

  11. Богдан

    'localhost$ scp ~/.ssh/id_rsa.pub youruser@remote.server.host'
    добавте ':~\' в конец.

  14. ssh-rsa

    У кого запрашивает пароль - вы вероятно не тот ключи скопировали. паблик ключ начинается с ssh-rsa

  16. viktor

    долго же я мучался, пытаясь понять что сделал не так. 100 раз перепроверил ключи, chmod'Ы... а сервер всё пишет: server refused your certificate. оказывается.... надо было указать владельца, после создания папки "mkdir .ssh".
    например chown $USER:$USER - вдруг кому поможет ... :-)