Как запустить ssh agent linux

Обновлено: 04.07.2024

Я вручную запускаю ssh-агент:

затем я добавляю агент:

затем он появляется, когда я делаю:

и я готов идти. Есть ли способ автоматизировать этот процесс, чтобы мне не приходилось делать это каждый раз при входе в систему? Сервер работает в RedHat 6.2 (Сантьяго).

пожалуйста, пройдите через эту статью. Вы можете найти это очень полезно:

на всякий случай, если вышеуказанная ссылка исчезнет когда-нибудь, я захватываю основную часть решения ниже:

данное решение от Reagle Джозеф М. путем Дэниел уставился:

добавьте это в свой .bash_profile

эта версия особенно приятно, так как он увидит, если вы уже запустили ssh-agent и, если он не может его найти, запустит его и сохранит настройки, чтобы они были полезны при следующем запуске оболочки.

в Arch Linux следующие работы действительно великолепны (должны работать на всех дистрибутивах на основе systemd):

создайте службу пользователя systemd, поместив следующее в

Setup shell, чтобы иметь переменную среды для сокета ( .bash_profile, .zshrc, . ):

включите службу, поэтому она будет запущена автоматически при входе в систему и запустите ее:

добавьте следующий параметр конфигурации в файл конфигурации ssh

/.ssh/config (эта работает с SSH 7.2):

это проинструктирует клиента ssh всегда добавлять ключ к работающему агенту, поэтому нет необходимости ssh-добавлять его заранее.

принятое решение имеет следующие недостатки:

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

если ваши ключи не требуют ввода пароля, я предлагаю следующее решение. Добавьте к вашему .bash_profile конец (отредактируйте список ключей потребности):

Он имеет следующие преимущества:

гораздо более простое решение;
сеанс агента заканчивается, когда сеанс bash заканчивается.

у него есть возможные недостатки:

интерактивные ssh-add команда будет влиять только на один сеанс, что на самом деле является проблемой только в очень нетипичных обстоятельствах;
непригодно, если требуется ввести пароль;
начатая оболочка становится не-логином (который не влияет ни на что AFAIK).

обратите внимание, что несколько ssh-agent процессы не являются недостатком, потому что они не занимают больше памяти или времени процессора.

старый вопрос, но я столкнулся с подобной ситуацией. Не думайте, что приведенный выше ответ полностью достигает того, что необходимо. Недостающая часть - keychain ; установите его, если он еще не установлен.

затем добавьте следующую строку в ваш

запуск ssh-agent если он не работает, подключитесь к нему, если это так, загрузите ssh-agent переменные среды в вашу оболочку и загрузите ключ ssh.

изменить id_rsa в зависимости от того, что частная ключ

/.ssh вы хотите загрузить.

ссылка

добавьте это в ваш

Это должно запрашивать пароль только при первом входе в систему после каждой перезагрузки. Он будет продолжать повторно использовать ssh-agent пока он работает.

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

/.ssh/.agent_env ). Если это есть, и есть сеанс работает, то источник среды и создать жесткую ссылку на файл сокета в /tmp (должен быть на та же файловая система, что и исходный файл сокета). По мере завершения сеансов bash каждый удаляет свою собственную жесткую ссылку. Последний сеанс для закрытия обнаружит, что жесткие ссылки имеют 2 ссылки (hardlink и оригинал), удаление собственного сокета процессов и убийство процесса приведет к 0, оставив чистую среду после закрытия последнего сеанса bash.

извините за опоздание:

пользователи рыбы оболочки можно использовать скрипт сделать то же самое.

чтобы добавить еще одно решение: P, я пошел с комбинацией решений @spheenik и @collin-anderson.

может быть немного более элегантным, но простым и читаемым. Это решение:

обеспечивает AddKeysToAgent yes находится в вашей конфигурации ssh, поэтому ключи будут автоматически добавлены при использовании
не предлагает вам вводить какие-либо парольные фразы при входе в систему (опять же, одноразовый ввод парольной фразы происходит при первом использовании)
молча начинает ssh-agent, если он еще не запустил один

Я решил это, добавив это в/etc / profile - system wide (или к локальному пользователю .профиль или. файл).

это запускает новый ssh-агент, если он не работает для пользователя, или повторно устанавливает параметр ssh-agent env при запуске.

Как ваши ответы большое. Он сделал работу из cygwin / linux хозяева намного проще. Я объединил функции start и end, чтобы сделать его безопасным.

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

Что такое SSH-agent

ssh-agent — это менеджер ключей для 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 и далее на удаленный хост. Вот как это работает:

Настройка ProxyJump

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

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

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

На этой странице описывается что такое ssh-agent, зачем он нужен и как правильно его использовать.

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

ssh-agent хранит секретные ключи и, когда нужно, пользуется ими. Программа (например, ssh), когда ей понадобится воспользоваться секретным ключом, не делает этого сама, а обращается к ssh-agent 'у, который в свою очередь уже сам пользуется известными только ему данными о секретных ключах. Таким образом, секретные ключи не разглашаются никому, даже программам принадлежащим самому пользователю.

Программу ssh-agent можно использовать двумя разными способами:

ssh-agent опции ssh-agent опции команда

В обоих случаях ssh-agent создает файл-сокет с именем /tmp/ssh-XXXXXXXX/agent.ppid, через который осуществляется взаимодействие с агентом. Всем дочерним процессам агент при помощи переменных окружения SSH_AUTH_SOCK (в которой хранится имя файла-сокета) и SSH_AGENT_PID (в которой хранится идентификатор процесс агента) сообщает информацию о том, как с ним можно связаться.

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

При указании ключа -c агент использует синтаксис C Shell. По умолчанию (и при явном указании ключа -s) используется синтаксис Bourne Shell. Эти переменные следует установить в текущем командном интерпретаторе, поэтому обычно вызов ssh-agent комбинируется с командой eval.

Во втором случае агент экспортирует значения переменных в среду окружения и порождает дочерний процесс, выполняя в нем команду. Достигается аналогичный результат, только при этом порождается дополнительный процесс.

Для того чтобы использовать ssh-agent в системе X Window, нужно добавить строку
eval `ssh-agent -s`; ssh-add < /dev/null
в скрипт, который выполняется перед запуском оконного менеджера. Таким файлом может быть, например,

Агент работает до тех пор, пока не будет явно завершен сигналом либо вызовом

В последнем случае должна быть доступна переменная SSH_AGENT_PID, которая хранит PID агента. Поэтому команда вызванная не из дочернего процесса, например, из другой консоли, действовать не будет.

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

Синтаксис команды ssh-add:

%$ ssh-add options file

При вызове без параметров ssh-add сообщает агенту информацию о ключах из файлов identity, id_dsa и id_rsa. При этом программа спрашивает парольную фразу для каждого из ключей (или, если фразы совпадают, всего один раз). Ключ, для которого правильно была введена парольная фраза передается агенту.

Если в качестве аргумента командной строки указан файл, программа сообщает агенту информацию только о том ключе, который находится в файле.

Список известных агенту секретных ключей можно посмотреть той же командой ssh-add с ключом командной строки -l. Команда сообщит и отпечаток для каждого ключа.

В этом посте посмотрим примеры работы с ssh-agent и то, как можно хранить и управлять запароленными RSA-ключами без таких бекендов.

ssh-agent

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

Запуск агента

SSH_AUTH_SOCK=/tmp/ssh-dMDE5mED77tM/agent.436347; export SSH_AUTH_SOCK;

Для работы клиентов важны переменные, которые задаются агентом:

SSH_AGENT_PID : с PID процесса с ssh-agent , которая будет использоваться при, например, ssh-agent -k для остановки агента
SSH_AUTH_SOCK : указывает на путь к unix-сокету, который будут использовать другие процессы для коммуникации с ssh-agent

Вариантов запуска много, рассмотрим их в конце, в Запуск ssh-agent и несколько консолей.

Примеры

Рассмотрим базовые примеры использования ssh-agent .

Создание ключа

ssh-keygen -t rsa -b 2048 -f /home/setevoy/.ssh/test-key -C "Testing key" -P pass Your identification has been saved in /home/setevoy/.ssh/test-key. Your public key has been saved in /home/setevoy/.ssh/test-key.pub. SHA256:pTyrGtk1hnNHB6b8ilp5jRe1+K4KrLHg50yUGilApLY Testing key

-t : тип RSA
-b : длина ключа в битах (по-умолчанию 3072 для RSA)
-f : путь к файлу ключа (по-умолчанию будет

Проверка пароля

Смена пароля

Что бы изменить пароль, заня старый:

Your identification has been saved with the new passphrase.

Скопировать ключ можно вручную, получив его публичную часть:

И скопировав содержимое в файл

/ .ssh/authorized_keys на удалённом хосте.

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/setevoy/.ssh/test-key.pub" /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys Now try logging into the machine, with: "ssh 'setevoy@rtfm.co.ua'" and check to make sure that only the key(s) you wanted were added.

И пробуем подключиться, используя этот ключ:

ssh-add

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

Проверим, что агент запущен:

setevoy 1322 0.0 0.0 5796 456 ? Ss Nov30 0:00 ssh-agent -s setevoy 1324 0.0 0.0 5796 2160 ? Ss Nov30 0:00 ssh-agent -s

Could not open a connection to your authentication agent

Could not open a connection to your authentication agent.

Первым делом проверяем SSH_AGENT_PID (или $SSH_AUTH_SOCK , т.к. запросы от ssh-add выполняются через сокет, заданный в этой переменной):

ssh-agent был запущен в другом терминале (об этом тоже поговорим ниже), поэтому перезапустим его.

И запускаем заново:

Проверяем ещё раз:

Добавление ключа

Проверка ключей в агенте

Проверяем загруженные в агент ключи, используя -l :

2048 SHA256:pTyrGtk1hnNHB6b8ilp5jRe1+K4KrLHg50yUGilApLY Testing key (RSA)

Удаление ключа

Используем -d для удаления одного ключа:

Или -D для удаления всех ключей:

Автоматическое добавление в ssh-agent

Выполняем подключение, вводим пароль ключа:

Отключаемся, проверяем ключи в агенте:

2048 SHA256:pTyrGtk1hnNHB6b8ilp5jRe1+K4KrLHg50yUGilApLY Testing key (RSA)

Запуск ssh-agent и несколько консолей

Could not open a connection to your authentication agent.

Но тогда для каждой сессии bash будет запускаться новый агент.

Ещё одним вариантом запуска через .bashrc может быть такой:

Тут выполняется (см. коды ответа ssh-agent в документации):

пытается выполнить ssh-add -l , перенаправляет весь вывод в /dev/null
проверяет код выхода предыдущей комнады
1. если код == 2 (ошибка подключения к агенту)
  1. проверяет доступен ли на чтение
  systemd
  
  Добавляем каталог, если не создан:
  
  Далее, Wiki говорит про файл
  
  /.pam_environment , но у меня Openbox и я переменные обычно задаю в .config/openbox/autostart :
  
  Останавливаем запущенные инстансы агента:
  
  Сейчас задаём переменную $SSH_AUTH_SOCK вручную:
  
  И запускам агент через systemctl --user :
  Loaded: loaded (/home/setevoy/.config/systemd/user/ssh-agent.service; disabled; vendor preset: enabled) Active: active (running) since Sun 2019-12-01 09:15:18 EET; 2s ago CGroup: /user.slice/user-1000.slice/user@1000.service/ssh-agent.service └─497687 /usr/bin/ssh-agent -D -a /run/user/1000/ssh-agent.socket Dec 01 09:15:18 setevoy-arch-pc systemd[670]: Started SSH key agent. Dec 01 09:15:19 setevoy-arch-pc ssh-agent[497687]: SSH_AUTH_SOCK=/run/user/1000/ssh-agent.socket; export SSH_AUTH_SOCK; Dec 01 09:15:19 setevoy-arch-pc ssh-agent[497687]: echo Agent pid 497687;
  И пробуем ssh-add :
  
  Можно добавить в автозапуск:
  Created symlink /home/setevoy/.config/systemd/user/default.target.wants/ssh-agent.service → /home/setevoy/.config/systemd/user/ssh-agent.service.
  
  Читайте также: