How to use ssh-agent for authentication on Linux / Unix
Tutorial requirements
Requirements
Linux, macOS, *BSD and Unix-like
Root privileges
No
Difficulty
Easy
Est. reading time
5m
Table of contents
Using ssh-agent command for non-interactive authentication
Open the terminal and type the following command: $ eval $(ssh-agent) $ eval `ssh-agent` You will see the PID of the ssh-agent as follows on screen:
Use ssh-add to add the private key passphrase to ssh-agent
Now our ssh-agent is running, and you need to provide the passphrase for your ssh private keys. For example, run the ssh-add command: $ ssh-add Type the passphrase:
By default it adds the files
/.ssh/id_ed25519_sk. But, we state another private key file as follows: $ ssh-add
Setting up a maximum lifetime for identities/private keys
Pass the -t life to the ssh-add command to s a maximum lifetime when adding identities to an agent. The lifetime may be specified in seconds or in a time format specified in sshd_config file: $ ssh-add -t 1800 # 1800 seconds $ ssh-add -t 45m # 45 minutes $ ssh-add -t 3h42 # 3 hours 42 minutes Remember, you can configure GNOME/KDE or macOS desktop to run ssh-agent and unlock keys automatically when log-in. For example:
Use ssh-agent for ssh/sftp/scp command authentication
Once you add the private key (or keys) to the ssh-agent, all you have to do is use ssh, sftp, scp, and all other ssh commands. For instance, I will execute the ssh command for my FreeBSD backup server: $ ssh user@server $ ssh user@hostname_or_ip $ scp file.doc vivek@server1.cyberciti.biz:
/Documents/ # State the private key for public key authentication # $ ssh -i
The ssh-agent for non-interactive ssh authentication in action on my Ubuntu Linux desktop
How to list my private keys cached by ssh-agent
Run the following command to lists fingerprints of all identities/private keys: $ ssh-add -l
No ads and tracking
In-depth guides for developers and sysadmins at Opensourceflare✨
Join my Patreon to support independent content creators and start reading latest guides:
How to set up Redis sentinel cluster on Ubuntu or Debian Linux
How To Set Up SSH Keys With YubiKey as two-factor authentication (U2F/FIDO2)
How to set up Mariadb Galera cluster on Ubuntu or Debian Linux
A podman tutorial for beginners – part I (run Linux containers without Docker and in daemonless mode)
How to protect Linux against rogue USB devices using USBGuard
Join Patreon ➔
Want to see list all public key parameters of all identities: $ ssh-add -L
Deleting all cached ssh-agent private keys
Pass the -D option to the ssh-add command: $ ssh-add -D You will see confirmation as follows on screen:
Conclusion
In this quick tutorial, you learned how to use ssh-agent for authentication and list/clear out private keys from memory when needed under Linux or Unix-like systems. For further information, see OpenSSH documentation or use the man command to read man pages: $ man ssh-agent $ man ssh-add $ man ssh $ man sftp $ man scp $ man sshd_config
🐧 Get the latest tutorials on Linux, Open Source & DevOps via
Источник
Про SSH Agent
Введение
SSH-agent является частью OpenSSH. В этом посте я объясню, что такое агент, как его использовать и как он работает, чтобы сохранить ваши ключи в безопасности. Я также опишу переадресацию агента и то, как она работает. Я помогу вам снизить риск при использовании переадресации агента и поделюсь альтернативой переадресации агента, которую вы можете использовать при доступе к своим внутренним хостам через bastion’ы.
Что такое SSH-agent
ssh-agent — это менеджер ключей для SSH. Он хранит ваши ключи и сертификаты в памяти, незашифрованные и готовые к использованию ssh . Это избавляет вас от необходимости вводить пароль каждый раз, когда вы подключаетесь к серверу. Он работает в фоновом режиме в вашей системе, отдельно от ssh , и обычно запускается при первом запуске ssh .
Агент SSH хранит секретные ключи в безопасности из-за того, что он не делает:
Он не записывает никакой информации о ключах на диск.
Он не позволяет экспортировать ваши личные ключи.
Секретные ключи, хранящиеся в Агенте, могут использоваться только для одной цели: подписания сообщения.
Но если агент может только подписывать сообщения, как SSH шифрует и расшифровывает трафик?
При первом изучении открытых и закрытых ключей SSH естественно предположить, что SSH использует эти пары ключей для шифрования и дешифрования трафика. Именно так я и думал. Но это не тот случай. Пара ключей SSH используется только для аутентификации во время первоначального соединения.
Например, вот как проверяется ключ пользователя во время SSH-соединения, с точки зрения сервера:
Клиент предоставляет серверу публичный ключ.
Сервер генерирует и отправляет короткое случайное сообщение, прося клиента подписать его с помощью приватного ключа.
Клиент просит агента SSH подписать сообщение и пересылает результат обратно на сервер.
Сервер проверяет подпись, используя публичный ключ клиента.
Теперь у сервера есть доказательство того, что клиент владеет приватным ключом.
Позже в процессе соединения генерируется набор новых, эфемерных и симметричных ключей, которые используются для шифрования трафика сеанса SSH. Эти ключи могут даже не длиться весь сеанс; событие «rekey» происходит через регулярные промежутки времени.
Протокол агента
SSH использует сокет домена Unix для общения с агентом по протоколу SSH agent. Большинство людей используют ssh-agent , который поставляется с OpenSSH, но есть множество альтернатив с открытым исходным кодом.
Протокол агента настолько прост, что можно было бы написать базовый SSH-agent за день или два. Он имеет только несколько основных операций:
Добавить обычную пару ключей (публичный и расшифрованный приватный ключи)
Добавить ограниченную пару ключей (публичный и расшифрованный приватный ключи)
Добавить ключ (обычный или ограниченный) из смарт-карты (только публичный ключ)
Удалить ключ
Вывод списка ключей, хранящихся в агенте
Подпись сообщения ключом, хранящимся в агенте
Блокировка или разблокировка всего агента с помощью пароля
Что такое ограниченный ключ? Обычно это ключ, который либо имеет ограниченный срок службы, либо требует явного подтверждения пользователя при его использовании.
Команда ssh-add — это ваш шлюз к агенту SSH. Он выполняет все эти операции, кроме подписи. Когда вы запускаете ssh-add без каких-либо параметров, он будет сканировать ваш домашний каталог на наличие некоторых стандартных ключей и добавлять их в ваш агент. По умолчанию он ищет:
/.ssh/id_ecdsa
Как только вы добавите ключи к связке ключей, они будут автоматически использоваться ssh .
ssh-агент и macOS Keychain ssh-agent , поставляемый вместе с macOS, может хранить парольную фразу для ключей в macOS Keychain, что делает еще более простым повторное добавление ключей к агенту после перезагрузки. В зависимости от настроек Keychain вам все равно может потребоваться разблокировать его после перезагрузки. Чтобы сохранить ключевые парольные фразы в Keychain, выполните команду ssh-add -K [имя файла ключа] . Парольные фразы обычно хранятся в «Local Items». ssh-agent будет использовать эти сохраненные парольные фразы автоматически по мере необходимости.
Что такое переадресация агента
Функция переадресации агента позволяет вашему локальному агенту SSH связаться через существующее SSH-соединение и прозрачно аутентифицироваться на более удаленном сервере. Например, предположим, что вы входите по SSH в инстанс EC2 и хотите клонировать оттуда приватный репозиторий GitHub. Без переадресации агента вам придется хранить копию вашего приватного ключа GitHub на хосте EC2. При переадресации агента SSH-клиент на EC2 может использовать ключи на вашем локальном компьютере для аутентификации на GitHub.
Как работает переадресация агента
Во-первых, немного предыстории. SSH-соединения могут иметь несколько каналов. Вот распространенный пример: интерактивное соединение с bastion-host (jump box) выполняется на одном канале. Когда для соединения включена переадресация агента (обычно с использованием ssh -A ), в фоновом режиме открывается второй канал для переадресации любых запросов агента обратно на ваш локальный компьютер.
С точки зрения ssh , нет никакой разницы между удаленным и локальным ssh-agent . SSH всегда смотрит на переменную окружения $SSH_AUTH_SOCK , чтобы найти доменный сокет Unix для агента. При подключении к удаленному хосту с включенной переадресацией агента SSHD создаст удаленный доменный сокет Unix, связанный с каналом переадресации агента, и экспортирует $SSH_AUTH_SOCK , указывающий на него.
Переадресация агента связана с определенным риском
Когда вы переадресовываете доменный сокет ssh-agent Unix на удаленный хост, это создает угрозу безопасности: любой человек с root доступом на удаленном хосте может незаметно получить доступ к вашему локальному SSH-agent’y через сокет. Они могут использовать ваши ключи, чтобы выдавать себя за вас на других машинах в сети.
Вот пример того, как это может выглядеть:
Как снизить свой риск при переадресации агента
Вот несколько способов сделать переадресацию агента более безопасной:
Не включайте ForwardAgent по умолчанию.
Заблокируйте свой ssh-агент, когда вы используете переадресацию агента. ssh-add -x блокирует агент паролем, а ssh-add -X разблокирует его. Когда вы подключены к удаленному хосту с переадресацией агента, никто не сможет проникнуть в ваш агент без пароля.
Или используйте альтернативный агент SSH, который запрашивает вас, когда он используется. Sekey использует Touch ID на macOS для хранения ключей в анклаве безопасности MacBook Pro.
Или вообще не используйте переадресацию агента. Если вы пытаетесь получить доступ к внутренним хостам через bastion, ProxyJump — гораздо более безопасная альтернатива для этого варианта использования. (смотреть ниже)
Используйте ProxyJump : более безопасная альтернатива
Когда вы хотите пройти через bastion-host (jumpbox), вам действительно не нужна переадресация agent’a. Лучший подход — использовать директиву ProxyJump .
Вместо того чтобы перенаправлять agent’a по отдельному каналу, ProxyJump перенаправляет стандартный вход и выход вашего локального SSH-клиента через bastion и далее на удаленный хост. Вот как это работает:
Запустите ssh -J bastion.example.com cloud.computer.internal для подключения к cloud.computer.internal через ваш bastion хост — bastion.example.com . cloud.computer.internal — это имя хоста, которое можно найти с помощью поиска DNS на bastion.example.com .
Ваш SSH клиент использует ключи от вашего агента для подключения к bastion.example.com .
После подключения SSHD к bastion подключается к cloud.computer.internal и передает это соединение вашему локальному SSH-клиенту.
Ваш локальный SSH-клиент снова проходит через соединение, на этот раз с cloud.computer.internal
Вы можете думать об этом как о SSH в сеансе SSH; за исключением того, что ssh никогда не запускается на bastion. Вместо этого sshd подключается к cloud.computer.internal и дает контроль над этим соединением (стандартный вход и выход) обратно в ваш локальный SSH, который затем выполняет второе соединение.
Скажем bastion-host это bastion.example.com . Я могу настроить свой
Затем я просто запускаю ssh cloud.computer.internal для подключения к внутреннему назначению через bastion — без переадресации агента.
Если ProxyJump не работает…
Более старые версии SSH и SSHD (до версии 7.2, выпущенной в 2016 году) не поддерживают ProxyJump . Но вы можете выполнить эквивалентную операцию, используя ProxyCommand и netcat. Вот вам пример:
Магия здесь заключается в том, что SSH сам по себе является прокси-сервером, который вы используете для SSH. Часть nc %h %p просто открывает необработанное соединение сокета к cloud.computer.internal на порте 22. Стандартный ввод-вывод родительской команды ssh передается прямо в ProxyCommand , чтобы родительский ssh мог аутентифицироваться на внутреннем хосте через прокси-соединение.
Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя онлайн-курсы SkillFactory:
Источник
5 UNIX / Linux ssh-agent Command Examples to Manage SSH Private Keys
ssh-agent is used to hold the private keys of remote server, which can be used to authenticate from the local machine.
The idea is once you add private keys using ssh-add command to the ssh-agent, you can login to the remote machine without having to enter the password.
If you are new to this, you should first understand how ssh-add command works.
1. Start the ssh-agent
You can start the ssh-agent from your session, as shown below. By default, you can start it without any parameter as shown below.
In this case, the parent PID for the ssh-agent will be 1. So, it is not tied to the current terminal.
If you want to start ssh-agent only for your terminal session, it is recommend that you pass the shell command variable (i.e /bin/bash to the ssh-agent while starting it as shown below). In this case, the ssh-agent will be forked from the current terminal, as you see below, the parent PID of the ssh-agent is the current terminal’s bash process.
2. Stop / Kill the ssh-agent
While you can use kill -9 command to kill the ssh-agent process, it is recommend that you use the -k option as shown below.
3. Run ssh-agent in debug mode
For some reason, after you’ve added the keys ot the ssh-agent, if it still asks for password when you ssh to remote server, you may want to debug and see if ssh-agent has the right keys.
You can run ssh-agent in the debug mode as shown below. Please note that when you run in debug mode, it will run in the foreground mode.
4. Set Bind Socket Name
By default, the ssh-agent binds to a socket under /tmp directory (for example: SSH_AUTH_SOCK=/tmp/ssh-UMmVe11244/agent.11244). If you are concerned about this for security reasons, you can specify your own socket file name under your home directory (or anywhere else), instead of the /tmp directory.
The following example will use the my-ssh-socket file for the SSH_AUTH_SOCK.
After starting the ssh-agent, you can verify that the bind socket is created in the location you’ve specified.
When this ssh-agent is killed properly, this bind socket file will be deleted automatically by the ssh-agent as shown below.
5. Set Expiry Time for Keys
By default, the keys added to the ssh-agent doesn’t expire. They stay there as long as ssh-agent is running. However you can set an expire time using the -t option as shown below.
In the following example, the keys will expire after 3600 second, which is 1 hour.
You can also use one of the following time qualifiers
m | M minutes (for example: 5M for 5 minutes)
h | H hours (for example: 5h for 5 hours)
d | D days (for example: 5D for 5 days)
w | W weeks (for example 5w for 5 weeks)
In the following example, the keys will expire after 3 days.
