What is ssh agent in linux

Про SSH Agent

SSH-agent является частью OpenSSH. В этом посте я объясню, что такое агент, как его использовать и как он работает, чтобы сохранить ваши ключи в безопасности. Я также опишу переадресацию агента и то, как она работает. Я помогу вам снизить риск при использовании переадресации агента и поделюсь альтернативой переадресации агента, которую вы можете использовать при доступе к своим внутренним хостам через bastion’ы.

Что такое SSH-agent

ssh-agent — это менеджер ключей для SSH. Он хранит ваши ключи и сертификаты в памяти, незашифрованные и готовые к использованию ssh . Это избавляет вас от необходимости вводить пароль каждый раз, когда вы подключаетесь к серверу. Он работает в фоновом режиме в вашей системе, отдельно от ssh , и обычно запускается при первом запуске ssh .

Агент SSH хранит секретные ключи в безопасности из-за того, что он не делает:

• Он не записывает никакой информации о ключах на диск.
• Он не позволяет экспортировать ваши личные ключи.

Но если агент может только подписывать сообщения, как SSH шифрует и расшифровывает трафик?

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

Например, вот как проверяется ключ пользователя во время SSH-соединения, с точки зрения сервера:

• Клиент предоставляет серверу публичный ключ.
• Сервер генерирует и отправляет короткое случайное сообщение, прося клиента подписать его с помощью приватного ключа.
• Клиент просит агента SSH подписать сообщение и пересылает результат обратно на сервер.
• Сервер проверяет подпись, используя публичный ключ клиента.
• Теперь у сервера есть доказательство того, что клиент владеет приватным ключом.

Протокол агента

SSH использует сокет домена Unix для общения с агентом по протоколу SSH agent. Большинство людей используют ssh-agent , который поставляется с OpenSSH, но есть множество альтернатив с открытым исходным кодом.

Протокол агента настолько прост, что можно было бы написать базовый SSH-agent за день или два. Он имеет только несколько основных операций:

• Добавить обычную пару ключей (публичный и расшифрованный приватный ключи)
• Добавить ограниченную пару ключей (публичный и расшифрованный приватный ключи)
• Добавить ключ (обычный или ограниченный) из смарт-карты (только публичный ключ)
• Удалить ключ
• Вывод списка ключей, хранящихся в агенте
• Подпись сообщения ключом, хранящимся в агенте
• Блокировка или разблокировка всего агента с помощью пароля

Команда ssh-add — это ваш шлюз к агенту SSH. Он выполняет все эти операции, кроме подписи. Когда вы запускаете ssh-add без каких-либо параметров, он будет сканировать ваш домашний каталог на наличие некоторых стандартных ключей и добавлять их в ваш агент. По умолчанию он ищет:

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 через сокет. Они могут использовать ваши ключи, чтобы выдавать себя за вас на других машинах в сети.

Вот пример того, как это может выглядеть:

Как снизить свой риск при переадресации агента

Вот несколько способов сделать переадресацию агента более безопасной:

Заблокируйте свой 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 и далее на удаленный хост. Вот как это работает:

1. Запустите ssh -J bastion.example.com cloud.computer.internal для подключения к cloud.computer.internal через ваш bastion хост — bastion.example.com . cloud.computer.internal — это имя хоста, которое можно найти с помощью поиска DNS на bastion.example.com .
2. Ваш SSH клиент использует ключи от вашего агента для подключения к bastion.example.com .
3. После подключения SSHD к bastion подключается к cloud.computer.internal и передает это соединение вашему локальному SSH-клиенту.
4. Ваш локальный SSH-клиент снова проходит через соединение, на этот раз с cloud.computer.internal

Скажем bastion-host это bastion.example.com . Я могу настроить свой ~/.ssh/config так:

Host bastion.example.com User carl Host *.computer.internal ProxyJump bastion.example.com User carl

Затем я просто запускаю ssh cloud.computer.internal для подключения к внутреннему назначению через bastion — без переадресации агента.

Если ProxyJump не работает…

Более старые версии SSH и SSHD (до версии 7.2, выпущенной в 2016 году) не поддерживают ProxyJump . Но вы можете выполнить эквивалентную операцию, используя ProxyCommand и netcat. Вот вам пример:

ssh -o ProxyCommand="ssh bastion.example.com nc %h %p" cloud.computer.internal

Магия здесь заключается в том, что SSH сам по себе является прокси-сервером, который вы используете для SSH. Часть nc %h %p просто открывает необработанное соединение сокета к cloud.computer.internal на порте 22. Стандартный ввод-вывод родительской команды ssh передается прямо в ProxyCommand , чтобы родительский ssh мог аутентифицироваться на внутреннем хосте через прокси-соединение.

Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя онлайн-курсы SkillFactory:

Читать еще

Источник

ssh-agent: How to configure ssh-agent, agent forwarding, & agent protocol

The ssh-agent is a helper program that keeps track of users’ identity keys and their passphrases . The agent can then use the keys to log into other servers without having the user type in a password or passphrase again. This implements a form of single sign-on (SSO).

The SSH agent is used for SSH public key authentication . It uses SSH keys for authentication. Users can create SSH keys using the ssh-keygen command and install them on servers using the ssh-copy-id command.

Contents

Starting ssh-agent

On most Linux systems, ssh-agent is automatically configured and run at login, and no additional actions are required to use it. However, an SSH key must still be created for the user.

If ssh-agent is not automatically started at login, it can be started manually with the command

The ssh-agent command outputs commands to set certain environment variables in the shell. The commands output by default are compatible with /bin/sh and /bin/bash . To output commands for the C-shell ( /bin/csh or /bin/tcsh ), add -c .

The easiest way to check is to check the value of the SSH_AGENT_SOCK environment variable. If it is set, then the agent is presumably running. It can be checked by

Also, to allow key-based logins to servers, public key authentication must be enabled on the server. In OpenSSH it is enabled by default. It is controlled by the PubkeyAuthentication option in sshd_config .

Adding SSH keys to the Agent

By default, the agent uses SSH keys stored in the .ssh directory under the user’s home directory. The ssh-add command is used for adding identities to the agent. In the simplest form, just run if without argument to add the default files ~/.ssh/id_rsa , .ssh/id_dsa , ~/.ssh/id_ecdsa , ~/.ssh/id_ed25519 , and ~/.ssh/identity . Otherwise, give it the name of the private key file to add as an argument.

The following command will list private keys currently accessible to the agent:

SSH Agent Forwarding

Furthermore, the SSH protocol implements agent forwarding, a mechanism whereby an SSH client allows an SSH server to use the local ssh-agent on the server the user logs into, as if it was local there. When the user uses an SSH client on the server, the client will try to contact the agent implemented by the server, and the server then forwards the request to the client that originally contacted the server, which further forwards it to the local agent. This way, ssh-agent and agent forwarding implement single sign-on that can progress transitively.

A wonderful feature of the single sign-on provided by SSH is that it works independent of organizational boundaries and geography. You can easily implement single sign-on to servers on the other side of the world, in cloud services, or at customer premises. No central coordination is needed.

To use agent forwarding, the ForwardAgent option must be set to yes on the client (see ssh_config ) and the AllowAgentForwarding option must be set to yes on the server (see sshd_config ).

Running ssh-agent

The ssh-agent command is usually run from initialization scripts at login, such as from /etc/X11/Xsession.d/90×11-common_ssh-agent on Linux Mint LMDE. Alternatively, any user can configure it to be run from, e.g., the user’s ~/.xsession file or ~/.profile .

The agent outputs environment variable settings that this puts in place. The SSH_AUTH_SOCK environment variable is set to point to a unix-domain socket used for communicating with the agent, and the SSH_AGENT_PID environment variable is set to the process ID of the agent. To get the environment variables set in the user’s shell environment, the agent is usually run with something like the following:

The ssh-agent command accepts the following options:

-a bind_address

Forces to bind the Unix domain socket to the given file path, instead of the default socket.

Forces generation of C-shell commands on stdout. By default the shell is automatically detected.

-E fingerprint_hash Specifies which algorithm to use for generating SSH key fingerprints. Valid values include md5 and sha256 .

Kills the currently running agent.

Forces generation of Bourne shell ( /bin/sh ) commands on stdout. By default the shell is automatically detected.

Specifies a maximum number of seconds that identities are kept in the agent. The value is in seconds, but can be suffixed by m for minutes, h for hours, d for days, and w for weeks. Without this option, the agent keeps the keys in its memory as long as it runs. This can be overridden when running the ssh-add command.

Further Reading

Источник