Linux ssh key
3 мин для чтения Как добавить открытый ключ SSH на сервер
Главное меню » Linux » Как добавить открытый ключ SSH на сервер
Мы предполагаем, что вы понимаете основную концепцию SSH. На вашем сервере Linux включен ssh. Вы сгенерировали ключи ssh на своем персональном компьютере. Теперь вы хотите загрузить свой открытый ключ на авторизованные ключи сервера, чтобы вы могли получить к нему доступ без постоянного ввода пароля учетной записи.
В этой краткой статье показаны два метода добавления публичного ключа SSH на сервер.
Требования
Прежде чем вы это увидите, давайте проясним, что у вас уже должно быть:
- На целевом сервере должен быть включен ssh.
- Вы должны были сгенерировать открытые и закрытые ssh-ключи (просто используйте команду ssh-keygen -t rsa ).
- У вас должны быть учетная запись пользователя и пароль на сервере. Даже рут аккаунт подойдет.
- Вы должны знать IP-адрес сервера
Теперь, когда вы убедились в вышеупомянутых трех требованиях, давайте посмотрим, как использовать аутентификацию с открытым ключом.
Аутентификация для каждой пользовательской базы, поэтому открытый ключ отправляется в дом предполагаемого пользователя.
Способ 1: автоматически скопировать ключ ssh на сервер
Первый способ – это когда конечный пользователь копирует открытый ключ своего персонального компьютера в список разрешенных ключей на удаленном сервере.
Здесь мы предполагаем, что вы смогли войти на удаленный сервер, используя ssh user_name @ ip_of_server. Он запрашивает пароль вашей учетной записи, и вы заходите на сервер.
Если вы добавите свой открытый ключ на сервер, вы сможете войти в систему, не вводя пароль все время.
OpenSSH предоставляет удобный инструментальный вызов ssh-copy-id для копирования открытых ключей ssh в удаленные системы. Он даже создает необходимые каталоги и файлы.
Как мы упоминали ранее, вы должны знать имя пользователя и пароль для сервера, к которому вы хотите получить доступ через аутентификацию с открытым ключом.
При появлении запроса введите пароль для своей учетной записи на удаленном сервере. Ваш открытый ключ должен быть скопирован в соответствующую папку на удаленном сервере автоматически.
/.ssh/id_rsa.pub, потому что это местоположение по умолчанию для открытого ключа ssh. Если у вас есть его в другом месте, вы должны использовать это в приведенной выше команде.
Способ 2: вручную скопировать открытый ключ ssh на сервер
Первый метод имел действие на стороне пользователя. Допустим, вы – системный администратор, а ваш сервер не разрешает SSH вход через пароль. Единственный способ получить доступ к серверу – использовать аутентификацию с открытым ключом SSH.
В таком случае вы можете попросить конечного пользователя предоставить свой открытый ключ. Теперь вы можете создать каталог .ssh/authorized_keys, а затем скопировать открытый ключ здесь.
Позвольте нам показать эти шаги.
Шаг 1: Получить открытый ключ
Попросите конечного пользователя предоставить открытый ключ, введя следующую команду:
Это покажет длинную случайную строку, начинающуюся с ssh-rsa:
Вы можете получить этот текст по электронной почте или с помощью сообщений. Обычно это не должно быть проблемой.
Шаг 2: Создайте каталог ssh в домашнем каталоге пользователя (как системный администратор)
Помните, что вы должны создавать эти новые каталоги и файлы в домашнем каталоге конечного пользователя, а не в своем собственном (root/sysadmin).
Теперь откройте этот файл /home/user_name/.ssh/authorized_keys в текстовом редакторе, таком как Vim, и добавьте открытый ключ пользователя здесь:
Сохраните и закройте файл. Это почти готово.
Шаг 3: Установите соответствующее разрешение для файла
Наличие соответствующих прав доступа к файлу ssh очень важно, в противном случае вы увидите такие ошибки, как Permission denied (publickey).
Сначала убедитесь, что вы установили правильные права доступа к файлу:
Вы создали этот файл с правами администратора или root для другого пользователя. Вам нужно сменить владельца на пользователя:
Теперь, когда это сделано, вы можете попросить конечного пользователя войти на сервер.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
SSH: RSA-ключи и ssh-agent — управление SSH-ключами и их паролями
По ходу настройки keyring для Nextcloud-клиента (см. Linux: Nextcloud клиент, qtkeychain и ошибка «The name org.freedesktop.secrets was not provided by any .service files») — решил навести порядок в своих SSH-ключах, которых много, и аутентификация иногда преврашается в достаточно геморройный процесс.
В целом, для упрощения работы можно использовать системное хранилище секретов — gnome-keyring , либо KeeyPassXC, про них в другой раз.
В этом посте посмотрим примеры работы с ssh-agent и то, как можно хранить и управлять запароленными RSA-ключами без таких бекендов.
Примеры выполняются на Arch Linux (и, местами, для проверки — на Manjaro Linux с Budgie DE).
ssh-agent
ssh-agent предназначен для управления SSH-ключами пользователя и их паролями, что бы не вводить пароль к ключу каждый раз при использовании.
Запуск агента
Для работы клиентов важны переменные, которые задаются агентом:
- SSH_AGENT_PID : с PID процесса с ssh-agent , которая будет использоваться при, например, ssh-agent -k для остановки агента
- SSH_AUTH_SOCK : указывает на путь к unix-сокету, который будут использовать другие процессы для коммуникации с ssh-agent
Что бы запустить агента без вывода всей этой информации — используем:
Вариантов запуска много, рассмотрим их в конце, в Запуск ssh-agent и несколько консолей.
Примеры
Рассмотрим базовые примеры использования ssh-agent .
Создание ключа
- -t : тип RSA
- -b : длина ключа в битах (по-умолчанию 3072 для RSA)
- -f : путь к файлу ключа (по-умолчанию будет
/.ssh/id_rsa )
Проверка пароля
Что бы проверить пароль ключа — используем -f для указания ключа, и -y для вывода информации о ключе, поэтому запросит пароль:
Смена пароля
Что бы изменить пароль, заня старый:
ssh-copy-id — копирование ключа на сервер
Скопировать ключ можно вручную, получив его публичную часть:
И скопировав содержимое в файл
/ .ssh/authorized_keys на удалённом хосте.
Другой вариант — используя утилиту ssh-copy-id , которая, по сути, выполнит всё тоже самое, но при этом ещё и проверит права доступа на каталоги и файлы (самая частая проблема при использовании SSH-ключей для аутентификации):
И пробуем подключиться, используя этот ключ:
ssh-add
Окей, теперь у нас ключ для аутентификации на сервере, и ключ закрыт паролем.
При каждом обращении к серверу — нам придётся вводить пароль заново — Enter passphrase for key ‘/home/setevoy/.ssh/test-key’.
Что бы избежать этого — добавим ключ в ssh-agent , используя ssh-add .
Проверим, что агент запущен:
Could not open a connection to your authentication agent
Самая частая ошибка при использовании агента — когда к нему невозможно подключиться, и ssh-add сообщает:
Первым делом проверяем SSH_AGENT_PID (или $SSH_AUTH_SOCK , т.к. запросы от ssh-add выполняются через сокет, заданный в этой переменной):
ssh-agent был запущен в другом терминале (об этом тоже поговорим ниже), поэтому перезапустим его.
Для «чистоты эксперимента» — убиваем запущеные инстансы агента:
И запускаем заново:
-s используем для создания переменных, т.к. не все будут запускать из bash , а eval — что бы сразу выполнить експорт переменных ( export SSH_AUTH_SOCK ) из output самого ssh-agent .
Проверяем ещё раз:
Добавление ключа
Проверка ключей в агенте
Проверяем загруженные в агент ключи, используя -l :
Удаление ключа
Используем -d для удаления одного ключа:
Или -D для удаления всех ключей:
Автоматическое добавление в ssh-agent
Что бы ssh (и git , например) всегда добавляли ключ в ssh-agent без явного ручного вызова ssh-add — добавьте AddKeysToAgent в
Проверяем — сейчас ключей в агенте нет:
Выполняем подключение, вводим пароль ключа:
Отключаемся, проверяем ключи в агенте:
И теперь при повторном подключении — ключ уже будет взят из агента, и пароль вводить не потребуется:
Запуск ssh-agent и несколько консолей
Одна из основных проблем, это то, что при запуске новой вкладки в Konsole и инициализации новой bash-сесии — там не будет переменной $SSH_AUTH_SOCK , и ssh-клиент не сможет получить доступ к ключу.
Например, при вызове ssh-add в новом терминале получим уже упомянутую ошибку «Could not open a connection to your authentication agent«:
Вариантов много, например самый простой — добавить в
Но тогда для каждой сессии bash будет запускаться новый агент.
Ещё одним вариантом запуска через .bashrc может быть такой:
Тут выполняется (см. коды ответа ssh-agent в документации ):
- пытается выполнить ssh-add -l , перенаправляет весь вывод в /dev/null
- проверяет код выхода предыдущей комнады
- если код == 2 (ошибка подключения к агенту)
- проверяет доступен ли на чтение
/.ssh-agent-env , считывает его содержимое, и передаёт его в bash
- повторяет ssh-add -l
- если код по-прежнему 2:
- создаёт файл
/.ssh-agent-env с правами 660 (чтение и запись только владельцу)
- запускает ssh-agent , и перенаправляет его вывод в файл .ssh-agent-env
- считывает содержимое .ssh-agent-env , и передаёт его в bash
- выполняет ssh-add /home/setevoy/.ssh/test-key
- если код == 2 (ошибка подключения к агенту)
Более-менее вариант, т.к. во всех сессиях у нас будет использоваться один и тот же агент (хотя некоторые рекомендуют использовать различных агентов для разных пулов ключей, например для личных ключей — один агент, для рабочих — другой).
systemd
Ещё один вариант — создать systemd unit-файл и запускать ssh-agent как сервис, см. Arch Wiki .
Добавляем каталог, если не создан:
Далее, Wiki говорит про файл
/.pam_environment , но у меня Openbox и я переменные обычно задаю в .config/openbox/autostart :
Останавливаем запущенные инстансы агента:
Сейчас задаём переменную $SSH_AUTH_SOCK вручную:
И запускам агент через systemctl —user :
И пробуем ssh-add :
Можно добавить в автозапуск:
Ещё один вариант — запускать из
В таком случае, при вызове startx (как у меня, когда login manager нет, и X.Org запускается вручную, через вызов startx в консоли) будет запущен агент, а затем — Openbox, см. документацию :
Кроме того, как уже говорилось в начале — вместо самого ssh-agent можно использовать либо «обёртки», которые будут «проксировать» запросы от ssh-add и других клиентов к ssh-agent , либо полностью заменят ssh-agent , но об этом — в следующий раз.
Contents
- Русский
- English
- Deutsch
- Español
- Français
- Português
Share
Sign up for our newsletter.
Get the latest tutorials on SysAdmin and open source topics.
Write for DigitalOcean You get paid, we donate to tech non-profits.
DigitalOcean Meetups Find and meet other developers in your city.
Hacktoberfest Contribute to Open Source
Related
Как настроить ключи SSH в Ubuntu 18.04

Введение
SSH (secure shell, безопасная оболочка) представляет собой шифрованный протокол для администрирования и взаимодействия между серверами. Во время работы с сервером Ubuntu вы, скорее всего, будете проводить большую часть времени в вашем терминале, подключенном через SSH к вашему серверу.
В этом руководстве мы рассмотрим процесс настройки ключей SSH на вновь установленной Ubuntu. Ключи SSH представляют собой простой и безопасный способ входа на ваш сервер, и являются рекомендованным способом входа для всех пользователей.
Шаг 1 — Создание пары ключей RSA
Сперва создадим пару ключей на клиентской машине (обычно, это ваш компьютер):
По умолчанию ssh-keygen создаёт 2048-битную пару ключей RSA, которая достаточно безопасна для большинства сценариев использования (вы можете также добавить к этой команде флаг -b 4096 для получения 4096-битный ключей).
После ввода этой команды вы должны увидеть следующий вывод:
Нажмите Enter для сохранения пары ключей в директорию .ssh/ внутри вашей домашней директории или задайте другую директорию.
Если ранее вы уже генерировали пару SSH ключей, вы можете увидеть следующий вывод:
Если вы выберете перезаписать ключи на диск, вы не сможете использовать старые ключи для аутентификации. Будьте очень осторожны при выборе yes , это решение нельзя будет отменить.
Вы должны увидеть следующий вывод:
Здесь вы можете задать ключевую фразу (passphrase), что обычно рекомендуется сделать. Ключевая фраза добавляет дополнительный уровень безопасности для предотвращения входа на сервер неавторизованных пользователей. Для того, чтобы узнать больше о том, как это работает, рекомендуем ознакомиться с нашим руководством по настройке аутентификации по ключам SSH на серверах Linux.
Вы должны увидеть следующий вывод:
Теперь у вас есть пара из публичного и секретного ключей, которые вы можете использовать для аутентификации. Далее мы поместим публичный ключ на ваш сервер, для того, чтобы вы могли использовать аутентификацию по ключам SSH для входа.
Шаг 2 — Копирование публичного ключа на сервер Ubuntu
Самым быстрым способом скопировать ваш публичный ключ на машину с Ubuntu — использовать утилиту ssh-copy-id . Поскольку этот метод невероятно прост, он рекомендуется для использования в первую очередь. Если по какой либо причине использование ssh-copy-id невозможно, вы можете использовать один из двух альтернативных методов, описанных далее (копирование в входом по SSH с использованием пароля и ручное копирование ключа).
Копирование ключа с использованием ssh-copy-id
Утилита ssh-copy-id доступна по умолчанию во многих операционных системах, поэтому, скорее всего, она доступна и на вашей локальной машине. Для использования этого метода копирования ключа вам необходимо иметь доступ к своему серверу по SSH с использованием пароля.
Для использования утилиты вам необходимо указать адрес удалённого хоста, к которому вы хотите подключиться, а также имя пользователя, имеющего доступ к хосту по SSH. Именно для аккаунта этого пользователя и будет скопирован ваш публичный ключ SSH.
Синтаксис команды выглядит следующим образом:
Вы можете увидеть вывод следующего вида:
Это означает, что ваш локальный компьютер не узнал удалённый хост. Это случается, когда вы пытаетесь подключиться к новому хосту в первый раз. Напечатайте “yes” и нажмите ENTER для продолжения.
Далее утилита будет искать в директории вашего локального пользователя файл ключа id_rsa.pub , созданный нами ранее. Если файл ключа будет успешно обнаружен, утилита запросит пароль для входа на удалённый хост:
Введите пароль (при вводе он не будет отображаться из соображений безопасности) и нажмите ENTER . Утилита зайдёт на удалённый хост, используя данные аккаунта, пароль для которого вы ввели. Далее утилита скопирует содержимое файла публичного ключа из
/.ssh/id_rsa.pub в файл authorized_keys в поддиректории
/.ssh домашней директории вашего пользователя на удалённом хосте.
Вы должны увидеть следующий вывод:
Теперь ваш публичный ключ id_rsa.pub загружен на удалённый хост. Вы можете перейти к Шагу 3.
Копирование публичного ключа через SSH
Если у вас нет утилиты ssh-copy-id , но у вас есть пароль для входа по SSH на ваш удалённый сервер, мы можете загрузить свой ключ вручную.
Для этого можно использовать команду cat , которая прочитает содержимое файла публичного ключа на локальной машине, а затем мы сможем отправить прочитанные данные ключа по SSH на удалённый сервер.
Кроме этого, нам потребуется убедиться, что директория
/.ssh существует, а также имеет корректные права доступа для используемого нами аккаунта пользователя.
Далее мы сможем отправить содержимое файла ключа в файл authorized_keys внутри этой директории. Мы будем использовать синтаксис >> для добавление данных в конец файла вместо перезаписи содержимого файла. Это позволит нам добавить ключ без удаления ранее добавленных ключей.
Команда выглядит следующим образом:
Вы можете увидеть вывод следующего вида:
Это означает, что ваш локальный компьютер не узнал удалённый хост. Это случается, когда вы пытаетесь подключиться к новому хосту в первый раз. Напечатайте “yes” и нажмите ENTER для продолжения.
Далее вам будет предложено ввести пароль аккаунта пользователя на удалённом хосте:
После ввода пароля содержимое вашего файла публичного ключа id_rsa.pub будет скопировано в конец файла authorized_keys на удалённом хосте. Если всё прошло успешно, вы можете перейти к Шагу 3.
Копирование публичного ключа вручную
Если у вас нет доступа к вашей удалённой машине по SSH с использованием пароля, вам придётся проделать описанный выше процесс вручную.
Мы вручную добавим содержимое вашего файла id_rsa.pub в конец файла
/.ssh/authorized_keys на удалённой машине.
Для отображения содержимого файла id_rsa.pub введите следующую команду на вашей локальной машине:
Вы увидите содержимое файла ключа, выглядящее примерно так:
Зайдите на вашу удалённую машину любым доступным для вас способом.
Далее нам необходимо убедиться, что директория
/.ssh существует. Следующая команда создаст директорию, если её не существует или не сделает ничего, если директория была создана ранее:
Теперь вы можете создать или отредактировать файл authorized_keys внутри этой директории. Вы можете добавить содержимое файла id_rsa.pub в конец файла authorized_keys , при необходимости создав его, следующей командой:
В команде выше замените строка_публичного_ключа на вывод команды cat
/.ssh/id_rsa.pub , которую вы выполнили на своей локальной машине. Строка должна начинаться с ssh-rsa AAAA. .
Далее убедимся, что директория
/.ssh и файл authorized_keys имеют подходящие права доступа:
Эта команда удаляет права доступа для “group” и “other” для директории
Если вы используете аккаунт root для настройки ключей для аккаунта пользователя, важно, чтобы директория
/.ssh принадлежала этому самому пользователю, а не пользователю root :
В нашем руководстве мы используем пользователя с именем sammy , вам же следует использовать имя своего пользователя в команде выше.
Теперь мы можем попробовать аутентифицироваться на нашем Ubuntu сервере без пароля.
Шаг 3 — Аутентификация на сервере Ubuntu с использованием ключей SSH
Если вы успешно проделали описанные выше шаги по переносу публичного ключа, вы должны быть способны зайти на свой удалённый хост без использования пароля.
Процесс входа выглядит так же:
Если вы заходите на удалённый хост по SSH в первый раз, вы можете увидеть вывод следующего вида:
Это означает, что ваш локальный компьютер не узнал удалённый хост. Напечатайте “yes” и нажмите ENTER для продолжения.
Если при создании пары ключей вы не задали ключевую фразу (passphrase), вы будете залогинены автоматически. Если вы задали ключевую фразу, вам будет предложено её ввести (обратите внимание, что вводимые символы не будут отображаться на экране в целях безопасности). После аутентификации откроется новая сессия оболочки (shell session) на удалённом хосте от имени используемого вами удалённого аккаунта пользователя.
Если аутентификация по ключу прошла успешно, рекомендуем ознакомиться с тем, как далее повысить безопасность вашего сервера путём отключения входа по паролю.
Шаг 4 — Отключение аутентификации по паролю на вашем сервере
Если вам удалось войти в ваш удалённый аккаунт на удалённом хосте по SSH без ввода пароля, вы успешно настроили аутентификацию по ключу SSH для вашего аккаунта. Однако возможность входить на сервер с использованием пароля всё есть активна, что означает, что ваш сервер уязвим для атак с перебором пароля (brute-force attacks).
Перед тем как следовать дальнейшим инструкциям, убедитесь, что вы настроили аутентификацию по ключу SSH для вашего пользователя root или для пользователя с привилегиями sudo на вашем сервере. После завершения описанных далее процедур вход по паролю станет недоступен, поэтому очень важно убедиться, что у вас остаётся доступ к вашему серверу.
Как только вы убедитесь, что аккаунт вашего удалённого пользователя имеет привилегии администратора, войдите на сервер с использованием аутентификации по ключу SSH, используя либо аккаунт root , либо аккаунт пользователя с привилегиями sudo . Далее откройте конфигурационный файл демона SSH:
Внутри файла найдите директиву PasswordAuthentication . Она может быть закомментирована. Раскомментируйте её при необходимости и установите её значение в “no”. Это отключит возможность входа на сервер по паролю.
Сохраните и закройте файл нажав CTRL + X , затем Y для подтверждения сохранения файла, а далее ENTER для выхода из текстового редактора nano. Для применения внесённых изменений нам необходимо перезапустить сервис sshd :
В качестве меры предосторожности откройте новое окно терминала и проверьте, что соединение по SSH работает корректно, перед тем, как закрывать текущую сессию:
После проверки работоспособности SSH соединения, вы можете закрыть все открытые сессии с сервером.
Теперь демон SSH на вашем сервере с Ubuntu работает только с ключами SSH. Аутентификация по паролю полностью отключена.
Заключение
Теперь на вашем сервере настроен вход по ключам SSH, позволяющий заходить на сервер без использования пароля.
Если вы хотите узнать больше о том, как работать с SSH, рекомендуем наше руководство по работе с SSH.
Авторизация по ключу SSH
SSH или Secure Shell — это зашифрованный протокол, который часто используется для взаимодействия и удаленного управления серверами. Если вы захотите что-либо сделать на удаленном сервере, скорее всего, вам придется воспользоваться SSH и работать через терминал.
В SSH существует несколько способов авторизации. Вы можете каждый раз вводить пароль пользователя или использовать более безопасный и надежный способ — ключи SSH. Что самое интересное, он более удобен для применения, вам даже не нужно будет вводить пароль. В этой статье мы рассмотрим как настраивается авторизация по ключу SSH.
Как работают ключи SSH?
SSH сервер может выполнять аутентификацию пользователей с помощью различных алгоритмов. Самый популярный — это аутентификация по паролю. Он достаточно прост, но не очень безопасный. Пароли передаются по безопасному каналу, но они недостаточно сложны для противостояния попыткам перебора. Вычислительная мощность современных систем в сочетании со специальными скриптами делают перебор очень простым. Конечно, существуют другие способы дополнительной безопасности, например, fail2ban, но аутентификация по ключу SSH более надежна.
Каждая пара ключей состоит из открытого и закрытого ключа. Секретный ключ сохраняется на стороне клиента и не должен быть доступен кому-либо еще. Утечка ключа позволит злоумышленнику войти на сервер, если не была настроена дополнительная аутентификация по паролю.
Открытый ключ используется для шифрования сообщений, которые можно расшифровать только закрытым ключом. Это свойство и используется для аутентификации с помощью пары ключей. Открытый ключ загружается на удаленный сервер, к которому необходимо получить доступ. Его нужно добавить в специальный файл
Когда клиент попытается выполнить проверку подлинности через этот ключ, сервер отправит сообщение, зашифрованное с помощью открытого ключа, если клиент сможет его расшифровать и вернуть правильный ответ — аутентификация пройдена.
Как создать ключи SSH?
Сначала необходимо создать ключи ssh для аутентификации на локальном сервере. Для этого существует специальная утилита ssh-keygen, которая входит в набор утилит OpenSSH. По умолчанию она создает пару 2048 битных RSA ключей, которая подойдет не только для SSH, но и для большинства других ситуаций.
И так, генерация ключей ssh выполняется командой:
Утилита предложит вам выбрать расположение ключей. По умолчанию ключи располагаются в папке
/.ssh/. Лучше ничего не менять, чтобы все работало по умолчанию и ключи автоматически подхватывались. Секретный ключ будет называться id_rsa, а публичный id_rsa.pub.
Затем утилита предложит ввести пароль для дополнительного шифрования ключа на диске. Его можно не указывать, если не хотите. Использование дополнительного шифрования имеет только один минус — необходимость вводить пароль, и несколько преимуществ:
- Пароль никогда не попадет в сеть, он используется только на локальной машине для расшифровки ключа. Это значит что перебор по паролю больше невозможен.
- Секретный ключ хранится в закрытом каталоге и у клиента ssh нет к нему доступа пока вы не введете пароль;
- Если злоумышленник хочет взломать аутентификацию по ключу SSH, ему понадобится доступ к вашей системе. И даже тогда ключевая фраза может стать серьезной помехой на его пути.
Но все же, это необязательное дополнение и если не хотите, то вы можете просто нажать Enter. Тогда доступ по ключу ssh будет выполняться автоматически и вам не нужно будет что-либо вводить.
Теперь у вас есть открытый и закрытый ключи SSH и вы можете использовать их для проверки подлинности. Дальше нам осталось разместить открытый ключ на удаленном сервере.
Загрузка ключа на сервер
Когда генерация ключей завершена, нам осталось только загрузить ключ на сервер. Для загрузки ключа можно использовать несколько способов. В некоторых случаях вы можете указать ключ в панели управления сервером, например, сPanel или любой другой. Но мы такой способ рассматривать не будем. Мы рассмотрим ручные способы.
Самый простой способ скопировать ключ на удаленный сервер — это использовать утилиту ssh-copy-id. Она тоже входит в пакет программ OpenSSH. Но для работы этого метода вам нужно иметь пароль доступа к серверу по SSH. Синтаксис команды:
При первом подключении к серверу система может его не распознать, поэтому вам нужно ввести yes. Затем введите ваш пароль пользователя на удаленном сервере. Утилита подключится к удаленному серверу, а затем использует содержимое ключа id.rsa.pub для загрузки его на сервер в файл
/.ssh/authorized_keys. Дальше вы можете выполнять аутентификацию с помощью этого ключа.
Если такой способ по какой-либо причине для вас не работает, вы можете скопировать ключ по ssh вручную. Мы создадим каталог
/.ssh, а затем поместим наш ключ в файл authorized_keys с помощью символа >>, это позволит не перезаписывать существующие ключи:
/.ssh/id_rsa.pub | ssh username@remote_host «mkdir -p
Здесь вам тоже нужно набрать yes, если вы подключаетесь к новому серверу, а затем ввести пароль. Теперь вы можете использовать созданный ключ для аутентификации на сервере:
Если вы не захотели создать ssh ключ с доступом по паролю, то вы сразу же будете авторизованы, что очень удобно. Иначе, сначала вам придется ввести фразу-пароль для расшифровки ключа.
Отключение проверки пароля
Если пароль больше не будет использоваться, то для увеличения безопасности системы лучше его вовсе отключить. Но убедитесь, что ключ надежно сохранен и вы его не потеряете, потому что по паролю вы больше не войдете. Авторизуйтесь на сервере, затем откройте конфигурационный файл /etc/ssh/sshd_config и найдите там директиву PasswordAuthenticatin. Нужно установить ее значение в No:
sudo vi /etc/ssh/sshd_config
Теперь сохраните файл и перезапустите службу ssh:
sudo service ssh restart
Дальше будет возможно только подключение по ключу ssh, пароль не будет приниматься.
Выводы
В этой статье мы рассмотрели как выполняется авторизация по ключу ssh, настройка ключей ssh и добавить ssh ключ. Теперь вы можете войти на сервер без ввода пароля. Если у вас остались вопросы, спрашивайте в комментариях!
SSH: RSA-ключи и ssh-agent — управление SSH-ключами и их паролями
По ходу настройки keyring для Nextcloud-клиента (см. Linux: Nextcloud клиент, qtkeychain и ошибка «The name org.freedesktop.secrets was not provided by any .service files») — решил навести порядок в своих SSH-ключах, которых много, и аутентификация иногда преврашается в достаточно геморройный процесс.
В целом, для упрощения работы можно использовать системное хранилище секретов — gnome-keyring , либо KeeyPassXC, про них в другой раз.
В этом посте посмотрим примеры работы с ssh-agent и то, как можно хранить и управлять запароленными RSA-ключами без таких бекендов.
Примеры выполняются на Arch Linux (и, местами, для проверки — на Manjaro Linux с Budgie DE).
ssh-agent
ssh-agent предназначен для управления SSH-ключами пользователя и их паролями, что бы не вводить пароль к ключу каждый раз при использовании.
Запуск агента
Для работы клиентов важны переменные, которые задаются агентом:
- SSH_AGENT_PID : с PID процесса с ssh-agent , которая будет использоваться при, например, ssh-agent -k для остановки агента
- SSH_AUTH_SOCK : указывает на путь к unix-сокету, который будут использовать другие процессы для коммуникации с ssh-agent
Что бы запустить агента без вывода всей этой информации — используем:
Вариантов запуска много, рассмотрим их в конце, в Запуск ssh-agent и несколько консолей.
Примеры
Рассмотрим базовые примеры использования ssh-agent .
Создание ключа
- -t : тип RSA
- -b : длина ключа в битах (по-умолчанию 3072 для RSA)
- -f : путь к файлу ключа (по-умолчанию будет
/.ssh/id_rsa )
Проверка пароля
Что бы проверить пароль ключа — используем -f для указания ключа, и -y для вывода информации о ключе, поэтому запросит пароль:
Смена пароля
Что бы изменить пароль, заня старый:
ssh-copy-id — копирование ключа на сервер
Скопировать ключ можно вручную, получив его публичную часть:
И скопировав содержимое в файл
/ .ssh/authorized_keys на удалённом хосте.
Другой вариант — используя утилиту ssh-copy-id , которая, по сути, выполнит всё тоже самое, но при этом ещё и проверит права доступа на каталоги и файлы (самая частая проблема при использовании SSH-ключей для аутентификации):
И пробуем подключиться, используя этот ключ:
ssh-add
Окей, теперь у нас ключ для аутентификации на сервере, и ключ закрыт паролем.
При каждом обращении к серверу — нам придётся вводить пароль заново — Enter passphrase for key ‘/home/setevoy/.ssh/test-key’.
Что бы избежать этого — добавим ключ в ssh-agent , используя ssh-add .
Проверим, что агент запущен:
Could not open a connection to your authentication agent
Самая частая ошибка при использовании агента — когда к нему невозможно подключиться, и ssh-add сообщает:
Первым делом проверяем SSH_AGENT_PID (или $SSH_AUTH_SOCK , т.к. запросы от ssh-add выполняются через сокет, заданный в этой переменной):
ssh-agent был запущен в другом терминале (об этом тоже поговорим ниже), поэтому перезапустим его.
Для «чистоты эксперимента» — убиваем запущеные инстансы агента:
И запускаем заново:
-s используем для создания переменных, т.к. не все будут запускать из bash , а eval — что бы сразу выполнить експорт переменных ( export SSH_AUTH_SOCK ) из output самого ssh-agent .
Проверяем ещё раз:
Добавление ключа
Проверка ключей в агенте
Проверяем загруженные в агент ключи, используя -l :
Удаление ключа
Используем -d для удаления одного ключа:
Или -D для удаления всех ключей:
Автоматическое добавление в ssh-agent
Что бы ssh (и git , например) всегда добавляли ключ в ssh-agent без явного ручного вызова ssh-add — добавьте AddKeysToAgent в
Проверяем — сейчас ключей в агенте нет:
Выполняем подключение, вводим пароль ключа:
Отключаемся, проверяем ключи в агенте:
И теперь при повторном подключении — ключ уже будет взят из агента, и пароль вводить не потребуется:
Запуск ssh-agent и несколько консолей
Одна из основных проблем, это то, что при запуске новой вкладки в Konsole и инициализации новой bash-сесии — там не будет переменной $SSH_AUTH_SOCK , и ssh-клиент не сможет получить доступ к ключу.
Например, при вызове ssh-add в новом терминале получим уже упомянутую ошибку «Could not open a connection to your authentication agent«:
Вариантов много, например самый простой — добавить в
Но тогда для каждой сессии bash будет запускаться новый агент.
Ещё одним вариантом запуска через .bashrc может быть такой:
Тут выполняется (см. коды ответа ssh-agent в документации ):
- пытается выполнить ssh-add -l , перенаправляет весь вывод в /dev/null
- проверяет код выхода предыдущей комнады
- если код == 2 (ошибка подключения к агенту)
- проверяет доступен ли на чтение
/.ssh-agent-env , считывает его содержимое, и передаёт его в bash
- повторяет ssh-add -l
- если код по-прежнему 2:
- создаёт файл
/.ssh-agent-env с правами 660 (чтение и запись только владельцу)
- запускает ssh-agent , и перенаправляет его вывод в файл .ssh-agent-env
- считывает содержимое .ssh-agent-env , и передаёт его в bash
- выполняет ssh-add /home/setevoy/.ssh/test-key
- если код == 2 (ошибка подключения к агенту)
Более-менее вариант, т.к. во всех сессиях у нас будет использоваться один и тот же агент (хотя некоторые рекомендуют использовать различных агентов для разных пулов ключей, например для личных ключей — один агент, для рабочих — другой).
systemd
Ещё один вариант — создать systemd unit-файл и запускать ssh-agent как сервис, см. Arch Wiki .
Добавляем каталог, если не создан:
Далее, Wiki говорит про файл
/.pam_environment , но у меня Openbox и я переменные обычно задаю в .config/openbox/autostart :
Останавливаем запущенные инстансы агента:
Сейчас задаём переменную $SSH_AUTH_SOCK вручную:
И запускам агент через systemctl —user :
И пробуем ssh-add :
Можно добавить в автозапуск:
Ещё один вариант — запускать из
В таком случае, при вызове startx (как у меня, когда login manager нет, и X.Org запускается вручную, через вызов startx в консоли) будет запущен агент, а затем — Openbox, см. документацию :
Кроме того, как уже говорилось в начале — вместо самого ssh-agent можно использовать либо «обёртки», которые будут «проксировать» запросы от ssh-add и других клиентов к ssh-agent , либо полностью заменят ssh-agent , но об этом — в следующий раз.