Я создал новую учетную запись для друга на Kubuntu 12.04. Когда он использует, ssh
он получает эту ошибку:
Не удалось открыть соединение с вашим агентом аутентификации
Мы работаем над ssh
некоторыми скриптами bash.
Посмотрев вокруг множества вещей, которые могут привести к этой ошибке, я наткнулся на это решение:
$ eval `ssh-agent -s`
$ ssh-add ~/.ssh/some_id_rsa
Затем он может запускать ssh
команды (и скрипты bash), как и ожидалось.
Перед выполнением этих двух команд переменные env не устанавливаются в терминале:
$ echo $SSH_AGENT_PID
$ echo $SSH_AUTH_SOCK
$
После выполнения команд переменные env устанавливаются в соответствии с ожиданиями. Однако они не остаются установленными (например, в другой оболочке или после перезагрузки).
Я хочу знать, как настроить его компьютер, чтобы ему не нужно было запускать эти две команды для установки переменных env. Мне не нужно запускать их на моем компьютере (никогда). Пока что я не вижу, чем отличаются наши машины.
Я вижу эту информацию на странице руководства, но она не говорит мне, как Ubuntu обычно настраивает агент автоматически или что происходит на компьютере моего друга, так что это не работает для него.
Существует два основных способа настройки агента: во-первых, агент запускает новую подкоманду, в которую экспортируются некоторые переменные среды, например, ssh-agent xterm &. Во-вторых, агент печатает необходимые команды оболочки (может быть сгенерирован либо синтаксис sh (1), либо csh (1)), которые можно оценить в вызывающей оболочке, например, eval
ssh-agent -s
для оболочек типа Борна, таких как sh (1) или ksh (1) и evalssh-agent -c
для csh (1) и производных.
После установки acct
и перезагрузки это вывод lastcomm
:
ssh-agent F newuser __ 0.12 secs Wed Aug 7 11:02
ssh-agent F newuser __ 0.00 secs Wed Aug 7 20:34
ssh-agent F newuser __ 0.02 secs Wed Aug 7 20:02
ssh-agent F newuser __ 0.01 secs Thu Aug 8 12:39
ssh-agent F newuser __ 0.02 secs Thu Aug 8 07:45
Со страницы руководства:
F - команда, выполненная после форка, но без следующего exec
Я не уверен, что это важно.
ssh-agent
обычно запускается из/etc/X11/Xsession.d/90x11-common_ssh-agent
. Это можно подавить, удаливuse-ssh-agent
из/etc/X11/Xsession
. Эти файлы правильны? Агент запущен и затем убит или никогда не запускался? (Установитеacct
и запуститеlastcomm
после входа в систему, чтобы увидеть, какие программы были запущены.)X11/Xsession.options:use-ssh-agent
иX11/Xsession.d/90x11-common_ssh-agent:SSHAGENT=/usr/bin/ssh-agent
. Я постараюсьacct
иlastcomm
дальше. Спасибоlastcomm
для полного сеанса, а не только дляssh-agent
процесса. Дело в том, чтобы увидеть, в каком порядке запускаются различные программы.Ответы:
Вы упомянули, что ваш пользователь входит
ssh
, а не локально. Таким образом,use-ssh-agent
in/etc/X11/Xsession.options
- это красная сельдь: она не будет выполняться в сеансах SSH, только при локальном входе в систему с графическим интерфейсом X11 (или при использовании некоторого виртуального сеанса X11, например, через VNC или RDP).Вместо этого вы должны проверить,
libpam-ssh
установлен ли он в любой системе. Он может быть настроен для аутентификации пользователя с использованием парольных фраз SSH, но это не является обязательным, и вам необходимо специально разместить ключ~/.ssh/login-keys.d/
для этой функции.Другая его функция, тем не менее, состоит в том, чтобы автоматически запускать агент SSH при любом сеансе входа в систему и автоматически добавлять закрытые ключи SSH к агенту, если их пароль совпадает с паролем для входа пользователя. Я думаю, что это может быть причиной различного поведения между вашими системами.
источник
Для
Конструкция для работы, когда она помещена в «сценарий запуска», ваш сеанс и, в конечном счете, терминал, в котором вы ожидаете среду, должны быть потомками (
fork
иexec
) этого сценария. Причина в том, что при оценке выходные данныеssh-agent -s
устанавливают переменные окружения в вызове оболочкиeval
. Форма там, они могут быть переданы, и они могут быть потеряны в пути.Так что если
ssh-agent
сценарий A выполняется где-то во время входа в систему, но терминал B, в котором вы запускаете сценарий оболочки, не является потомком A, то вы не сможете увидеть среду в B.Если вы
ssh-agent
запустили какsystemd --user
службу, то вам, возможно, придется использовать вместо этого соглашение: не позволяйтеssh-agent
указывать переменные, но используйте общие знания при запуске агента и при запуске сеанса. Например, моя~/.config/systemd/user/ssh-agent.service
выглядит так:И по моему у
~/.profile
меня есть линияОбратите внимание, что
%t
в первом соответствует${XDG_RUNTIME_DIR}
во втором.Примечание: я не рад этому!
источник
Я нашел ответ здесь:
http://www.bernatchez.net/userauth.html
В Ubuntu утилите ssh-add не удается загрузить файлы сертификатов. Это происходит, когда агент реализован gnome-keyring. Исправление состоит в том, чтобы прекратить использование ssh-компонента gnome-keyring. Поскольку процесс инициализации фактически запускает истинного ssh-агента, а затем запускает gnome-keyring-ssh.desktop, который захватывает AUTH_SOCKET, чтобы принять его, мы можем вернуться к исходному ssh-agent, отключив gnome-keyring-ssh.desktop.
Отключить gnome-keyring-ssh.desktop:
Добавьте следующую строку в файл рабочего стола и сохраните его, затем перезагрузите компьютер:
источник
Вы упомянули, что
работает по желанию. Поэтому вам просто нужно выполнить их в нужное время, в .bash_profile или .xsession. Добавьте отладочные операторы вроде,
(date; env|sort) >> /tmp/log
чтобы помочь вам точно понять, когда они выполняются.источник