Вы упомянули, что ваш пользователь ssh
входит в систему, а не локально. Таким образом, use-ssh-agent
в /etc/X11/Xsession.options
является отвлекающим маневром :, он не будет выполняться в сеансах SSH, только при локальном входе в рабочий стол с графическим интерфейсом X11 (или с использованием какого-либо виртуального сеанса X11, например, через VNC или RDP ).
Вместо этого вам следует проверить, установлен ли libpam-ssh
в любой системе. Его можно настроить для аутентификации пользователя с использованием секретных фраз-паролей SSH, но это необязательно, и вам нужно специально поместить ключ в ~/.ssh/login-keys.d/
для этой функции.
Однако его другая функция заключается в автоматическом -запуске агента SSH при любом сеансе входа в систему и автоматическом добавлении закрытых ключей SSH к агенту, если их парольная фраза совпадает с паролем пользователя для входа. Я думаю, что это может быть причиной различного поведения между вашими системами.
Для
$ eval `ssh-agent -s`
Чтобы конструкция работала в «сценарии запуска», ваш сеанс и, в конечном счете, терминал, в котором вы ожидаете среду, должны быть потомками (по fork
иexec
)этого сценария. Причина в том, что вывод ssh-agent -s
при оценке устанавливает среду переменные в оболочке, вызывающей eval
. Сформировавшись там, они могут быть переданы по наследству, а также могут быть потеряны в пути.
Таким образом, если ssh-agent
запускается сценарием A где-то во время входа в систему, но терминал B, в котором вы запускаете сценарий оболочки, не является потомком A, то вы не можете видеть окружение в B.
Если вы запустили ssh-agent
как службу systemd --user
, тогда вам, возможно, придется использовать вместо этого соглашение :Не позволяйте ssh-agent
указать переменные, но использовать общие знания при запуске агента и при запуске сеанса. например, мой ~/.config/systemd/user/ssh-agent.service
выглядит так:
[Unit]
Description=SSH agent
[Service]
Type=simple
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK
[Install]
WantedBy=default.target
А в моем ~/.profile
у меня есть строчка
export SSH_AUTH_SOCK="${XDG_RUNTIME_DIR}/ssh-agent.socket"
Обратите внимание, что %t
в первом соответствует ${XDG_RUNTIME_DIR}
в последний.
Примечание:Я не в восторге от этого!
Я нашел ответ здесь:
http://www.bernatchez.net/userauth.html
В Ubuntu утилите ssh -add не удается загрузить файлы сертификатов. Это происходит, когда агент реализуется связкой ключей gnome -. Исправление состоит в том, чтобы прекратить использование ssh-компонента набора ключей gnome -. Поскольку процесс инициализации фактически запускает настоящий агент ssh -, а затем запускает связку ключей gnome --ssh.desktop, которая стирает AUTH _SOCKET, чтобы взять его на себя, мы можем вернуться к исходному ssh -. ] агент, отключив gnome -связку ключей -ssh.desktop.
Отключить gnome -keyring -ssh.desktop:
cd /etc/xdg/autostart/
sudo emacs gnome-keyring-ssh.desktop
Добавьте следующую строку в файл рабочего стола и сохраните его, затем перезагрузите:
X-GNOME-Autostart-enabled=false
Вы упомянули, что
$ eval `ssh-agent -s`
$ ssh-add ~/.ssh/some_id_rsa
работает как надо. Так что вам просто нужно, чтобы они выполнялись в нужное время, в профиле.bash _или.xsession. Добавьте операторы отладки, такие как (date; env|sort) >> /tmp/log
, чтобы помочь вам точно понять, когда они выполняются.
Попытка настроить SSH -Keygen в многопользовательской -среде Jupyter Python оказалась большим разочарованием... Это, конечно, явно предпочтительнее обычного текста http пароль для git.
Я не понимал, что SSH_AUTH_SOCK
не переносится в мой ssh-add
после запуска eval ssh-agent
cmd... @stefan дал очень хорошее описание выше, которое поставило это все в перспективе! Более полезная информация о ssh -добавить справочную страницу здесь а также...
Ниже приведен пример инструкций с GitHub здесь по генерации ключа ssh.
!
(bang )в ячейке python, поэтому он запускает команду bash в jupyter. Подробнее здесь . && \
, чтобы обернуть мою команду bash внутри ячейки блокнота jupyter python, чтобы это была ОДНА команда:!ssh-keygen -t ed25519 -C "YOUR_EMAIL@domain.com" -f $HOME/.ssh/id_rsa -N "" <<< y && \
eval "$(ssh-agent -s)" && \
ssh-add $HOME/.ssh/id_rsa
Продолжайте, добавив свой SSH-ключ на github. После этого вы сможете подтвердить свою аутентификацию на github , у меня это сработало при запуске следующего:
!ssh -o "StrictHostKeyChecking no" -T user@hostgit@github.com
-o "StrictHostKeyChecking no"
является НЕ рекомендуемым, поскольку в -средней атаке -может быть человек -. Я не уверен, как программно принять это со значением да , в качестве альтернативы вы, вероятно, можете получить известный хост и вручную добавить его в файл известного хоста.