У вас есть отдельно стоящий сервер? Ходите на него через ssh? Пароль в целях безопасности больше 10 символов? В день заходите на сервер n-ное количество раз? Реально задолбало вводить каждый раз пароль на вход? Меня тоже
А выход как всегда прост до безобразия, потому что все уже придумано до нас.
Ключи SSH. Или метод Identity/Pubkey
При использовании метода идентификации Identity/Pubkey исключается использования статических паролей. Дабы каждый раз не набирать пароли, которые можно перехватить кейлоггером ну или просто подсмотреть, мы будем хранить на диске пару ключей, которые и будут использоваться для проверки подлинности. Вот некоторые из положительных моментов этого типа аутентификации:
- Никто не сможет войти на сервер с Вашей учетной записью, так как им необходимо обладать приватным ключом и кодовой фразой.
- Администратор сервера может вообще убрать пароль учетной записи, дабы исключить его дискредитацию.
- Вы можете использовать утилиту ssh-agent и он будет предоставлять аутентификационные данные за Вас.
- Вы можете устанавливать определенные ограничения, например запрещая перенаправление портов, выполнение определенных программ и т.д.
Генерация SSH ключей. Или создание Identity/Pubkey
Для генерации пары ключей нам необходимо воспользоваться утилитой ssh-keygen.
| 1 2 3 | ssh-keygen -t rsa |
Опцией -t rsa мы указали тип создаваемых ключей (возможны варианты ключей — rsa1, rsa или dsa)
Настройка сервера SSH
Все вышеуказанные манипуляции мы делали на локальной машине, теперь надо поднастроить удаленную (сервер куда мы будем логиниться). Ключи есть, теперь необходимо разрешить данный тип аутентификации на сервере SSH. Сначала определим тип аутентификации — Pubkey или Identity, установив следующие настройки в sshd_config
| 1 2 3 4 5 6 7 8 9 10 11 12 | # 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, и проверяют наличие публичных ключей в файле $HOME/.ssh/authorized_keys. Необходимо проверить наличие этих строк в файле конфигурации /etc/ssh/sshd_config, если таковых нету — добавить и перезапустить сервис.
Копирование файла с ключом на удалённый хост
Два варианта
ssh-copy-id
Скорей всего у вас должна быть утилитка ssh-copy-id и с ее помощью
| 1 2 3 | ssh-copy-id -i ~/.ssh/id_rsa.pub youruser@remote.server.host |
«ручной» вариант
| 1 2 3 | 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' |
или такой
| 1 2 3 4 5 6 7 8 9 10 | # на локальном хосте ~/.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 |
Вроде все сделали, все настроили — пора пробовать
| 1 2 3 | ssh your_user@remote.server.host |
Должно пустить без пароля (если только вы не ставили пароль на сам ключ). upd: по совету Vladimir-а (см. первый комментарий), ставим более правильные права доступа (chmod) — на каталог ~/.ssh ставим 700
17 Комментарии
К ручному методу я бы добавил изменение прав на каталог (0700) и ключ (0600). Так безопаснее 🙂
Мда, сорри, не увидел второй блок 🙁 Но всё равно права на папку ~/.ssh лучше ставить 0700 — ибо смысл туда ходить посторонним, если всё равно на чтение ключей прав у них быть не должно?
Спасибо за совет, подкорректировал права доступа
И за плагин спасибо — разобрался, все работает.
В статье ошибка, нужно заменить:
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’
Таки да, вы правы
А ведь столько раз пересматривал запись и столько же раз делал по своей же инструкции и не заметил.
Спасибо большое, подправил
А как быть если к одному серверу нужно подключиться с разными authorized_keys как прописать в конфиге,,,
Все равно запрашивает пароль на удаленного юзера!
> А как быть если к одному серверу нужно подключиться с разными authorized_keys как прописать в конфиге,,,
Добавлять каждый ключик новой строчкой в ~/.ssh/authorized_keys
> Все равно запрашивает пароль на удаленного юзера!
Значит что-то не так делали. Инструкция рабочая.
у меня также запрашивает пароль но без пароля и даже с вводом пароля не пускает. Как исправить?
«Значит что-то не так делали. Инструкция рабочая.»
ну да, да….
автор
а если версия ssh2 не нужно ли создавать authorized_keys2 ?
а править конфиг файл не нужно?
Все эти действия проводятся на удалённой тачке. Разве этого достаточно?? А на локальной, если она под управлением linux? Или windows? В случае с виндой надо ещё с PUTTY.EXE колдовать.
‘localhost$ scp ~/.ssh/id_rsa.pub youruser@remote.server.host‘
добавте ‘:~\’ в конец.
Не работает
Только что проверил. Все работает.
У кого запрашивает пароль — вы вероятно не тот ключи скопировали. паблик ключ начинается с ssh-rsa
стоп ssh -i .ssh/id_rsa youruser@remote.server.host
долго же я мучался, пытаясь понять что сделал не так. 100 раз перепроверил ключи, chmod’Ы… а сервер всё пишет: server refused your certificate. оказывается…. надо было указать владельца, после создания папки «mkdir .ssh».
например chown $USER:$USER — вдруг кому поможет … 🙂