ssh-агент не встановлюється (SSH_AUTH_SOCK, SSH_AGENT_PID env vars не встановлено)


13

Я створив новий обліковий запис користувача для друга на Kubuntu 12.04. Під час використання sshвін отримує цю помилку:

Не вдалося відкрити з'єднання з вашим агентом аутентифікації

Ми працюємо sshв деяких сценаріях bash.

Оглянувши широке розмаїття речей, які можуть призвести до цієї помилки, я натрапив на таке рішення:

$ eval `ssh-agent -s`
$ ssh-add ~/.ssh/some_id_rsa

Тоді він може запускати sshкоманди (та скрипки скриптів), як очікувалося.

Перед запуском цих двох команд змінні env не встановлюються в терміналі:

$ echo $SSH_AGENT_PID

$ echo $SSH_AUTH_SOCK

$ 

Після запуску команд змінні env встановлюються як очікувалося. Однак вони не залишаються встановленими (наприклад, в іншій оболонці або після перезавантаження).

Я хочу знати, як налаштувати його комп’ютер, щоб він не мав запускати ці дві команди для встановлення змінних env. Мені не потрібно запускати їх на своєму комп’ютері (ніколи). Поки що я не бачу, що відрізняється між нашими машинами.

Я бачу цю інформацію на сторінці "man", але вона не говорить мені про те, як Ubuntu зазвичай автоматично налаштовує агент або що відбувається на машині мого друга, так що це не працює для нього.

Є два основні способи налаштування агента: Перший полягає в тому, що агент запускає нову підкоманду, в яку експортуються деякі змінні середовища, наприклад, ssh-agent xterm &. Друга полягає в тому, що агент друкує необхідні команди оболонки (може бути сформований синтаксис sh (1) або csh (1)), які можуть бути отримані в оболонці виклику, наприклад, eval ssh-agent -sдля оболонок типу Bourne, таких як sh (1) або ksh (1) та eval ssh-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 - команда, що виконується після вилки, але без наступного виконання

Я не впевнений, чи це важливо.


2
Під Ubuntu, ssh-agentяк правило, починається з /etc/X11/Xsession.d/90x11-common_ssh-agent. Це можна придушити, видаливши use-ssh-agentз /etc/X11/Xsession. Правильні ці файли? Агент запускається, а потім вбивається чи ніколи не починається? (Встановіть acctта запустіть lastcommпісля входу в систему, щоб побачити, які програми запущені.)
Gilles 'SO- перестаньте бути злим'

@ Жил-спасибі. Ці два файли однакові на моїй машині та на його машині. У нас обох є X11/Xsession.options:use-ssh-agentі X11/Xsession.d/90x11-common_ssh-agent:SSHAGENT=/usr/bin/ssh-agent. Спробую acctі lastcommдалі. Спасибі
MountainX

оновлене запитання
MountainX

все ще шукає рішення ...
MountainX

Будь ласка, опублікуйте результати lastcommдля повного сеансу, а не лише ssh-agentпроцесу. Сенс полягає в тому, щоб побачити в якому порядку запускаються різні програми.
Жил "ТАК - перестань бути злим"

Відповіді:


0

Ви згадали, що користувач sshувійшов, не ввівши локально. Так в use-ssh-agentін /etc/X11/Xsession.optionsє відволікаючим маневром: вона не буде виконана на SSH сесіях, тільки при вході в робочий стіл X11 GUI локально (або з допомогою якого - то віртуального сеансу X11 , як через VNC або RDP).

Натомість слід перевірити, чи libpam-sshвстановлена ​​вона в будь-якій системі. Він може бути налаштований для автентифікації користувача за допомогою парольних фраз приватного ключа SSH, але це необов'язково, і вам потрібно буде спеціально розмістити ключ ~/.ssh/login-keys.d/для цієї функції.

Іншою його особливістю є автоматичне запуск агента SSH на будь-якому сеансі реєстрації та автоматичне додавання SSH приватних ключів до агента, якщо їхня парольна фраза така, як пароль для входу користувача. Я думаю, що це може бути причиною різної поведінки між вашими системами.


3

Для

$ eval `ssh-agent -s`

побудований для роботи, коли його розміщують у «скрипті запуску», ваш сеанс і в кінцевому підсумку термінал, де ви очікуєте оточення, повинні бути нащадками (за forkта exec) цього сценарію. Причина полягає в тому, що вихід ssh-agent -s, коли оцінюється, задає змінні середовища в виклику оболонкиeval . Формуйте там, вони можуть бути передані, і вони можуть загубитися в дорозі.

Отже, якщо ssh-agentзапускається сценарій А десь під час входу в систему, але термінал 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}в другому.

Примітка: Я не радий цьому!


1

Тут я знайшов відповідь:

http://www.bernatchez.net/userauth.html

У ubuntu утиліта ssh-add не може завантажити файли сертифікатів. Це відбувається, коли агент - це той, який реалізується gnome-keyring. Виправлення полягає в тому, щоб припинити використання ssh компонента gnome-keyring. Оскільки процес ініціалізації насправді запускає справжній ssh-агент, а потім запускає gnome-keyring-ssh.desktop, який клобує AUTH_SOCKET, щоб перейняти його, ми можемо повернутися до початкового ssh-агента, відключивши gnome-keyring-ssh.desktop.

Вимкнути gnome-keyring-ssh.desktop:

cd /etc/xdg/autostart/
sudo emacs gnome-keyring-ssh.desktop

Додайте наступний рядок у файл робочого столу та збережіть його та перезавантажте:

X-GNOME-Autostart-enabled=false

0

Ви це згадали

$ eval `ssh-agent -s`
$ ssh-add ~/.ssh/some_id_rsa

працює за бажанням. Тож вам просто потрібні ті, які потрібно виконати в потрібний час, у .bash_profile або .xsession. Додайте заяви про налагодження, (date; env|sort) >> /tmp/logякі допоможуть вам зрозуміти, коли саме вони запущені.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.