Почему я не могу взаимодействовать со своим ssh-агентом? (например, ssh-добавьте, что-D не работает),
В моей системе Kubuntu 14.04 я пытаюсь управлять ключами со своим агентом SSH, но так или иначе это, кажется, игнорирует мой ssh-add команды. Посмотрите на это ниже, и Вы будете видеть то, что я имею в виду.
Перечислите текущие ключи
⟫ ssh-add -l 2048 60:6f:58:ef:7c:b0:ec:94:fb:fa:59:21:86:3d:fc:4c gert@e6230 (RSA)Этот ключ загружается во время начальной загрузки, но я ожидал некоторый ключ ECDSA, не RSA. Я не знаю этот ключ...
Удалите ключ из агента.
⟫ ssh-add -D All identities removed.yey! Но... это?
⟫ ssh-add -l 2048 60:6f:58:ef:7c:b0:ec:94:fb:fa:59:21:86:3d:fc:4c gert@e6230 (RSA)Какого черта? Это просто лжет мне.
Что продолжается здесь?
⟫ env | grep -i ssh SSH_AUTH_SOCK=/run/user/1000/keyring-eDJggO/sshДавайте посмотрим, какой процесс выполняет тот сокет.
⟫ sudo fuser -u /run/user/1000/keyring-eDJggO/ssh [sudo] password for gert: /run/user/1000/keyring-eDJggO/ssh: 9434(gert) ⟫ ps -p 9434 u USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND gert 9434 0.0 0.0 292528 7192 ? Sl 00:05 0:00 gnome-keyring-daemon [...]Что, черт возьми, брелок для ключей GNOME делает в моей системе KDE? Не был должен кошелек KDE быть моим агентом SSH здесь?
Это приводит к большему количеству вопросов, чем ответы, и меня оставляют с нефункциональным ssh-агентом.
В другой системе я не наблюдаю это поведение, и мне не удается найти различие в конфигурации. У обоих есть только установленный KDE, и установленные пакеты почти идентичны (управляемый Марионеткой).
3 ответа
Я всегда заканчиваю sudo склонный - добираются, удаляют - брелок для ключей гнома чистки так или иначе, сопровождаемый с перезапуском. человечность-sso зависит от него, но я не использую это, таким образом, никакие заботы.
ssh-агент, кажется, просто работает, как он должен впоследствии.
Я понимаю, что это - старый поток. Я использую xubuntu 16.04. Кажется, что ошибка все еще там. Я установил морского конька для управления ключами, и это работало.
Примечание: не ответ, решая основную проблему. Предоставьте новый ответ, если Вы думаете, что можно решить первопричину. Действительно необходимо продолжать читать, почему моим решением является просто ужасный взлом.
Вот объяснение на том, что происходит во время начальной загрузки, идентифицируя преступника.
Используя KDM (или LightDM), как входят в систему менеджер, X сессий порождены для Вас после входа в систему. Журнал в менеджере позволяет Вам выбирать X сессий (например, GNOME, KDE Plasma, и т.д.) на основе доступных в Вашей системе. Каталог /usr/share/xsessions содержит файлы для каждого из тех установленная настольная среда и Ваш пользователь, в котором сохраняется определенный выбор ~/.dmrc.
В то время как загрузки настольной среды после входа в систему, это загружает все сценарии в /etc/X11/Xsession.d/. В системе Kubuntu 14.04 я вижу /etc/X11/Xsession.d/90x11-common_ssh-agent там по умолчанию, инициализируя агент SSH. Как ожидалось.Отлично!
На практике однако мы видим разные вещи. Где делает gnome-keyring-daemon приезжайте с того времени и почему постоянный клиент ssh-agent не запущенный? Ну, брелок для ключей GNOME запускается двумя способами:
- Автоматический запуск XDG, в
/etc/xdg/autostart/gnome-keyring-ssh.desktop - Как Новомодное задание сессии в
/usr/share/upstart/sessions/gnome-keyring.conf
Все сценарии сначала проверяют значения среды, продолжатся ли они. Например.
[ -z "$SSH_AUTH_SOCK" ] || [ -z "$GPG_AGENT_INFO" ] || { stop; exit 0; }
Это делает это своего рода состоянием состязания, какой агент SSH на самом деле запускается. Сначала каждый побеждает. Фигурная скобка для более противных битов.
Каким образом это работает в одной машине надежно, и это не делает надежно в другом? X новомодных заданий сессии только запускаются когда DESKTOP_SESSION переменная среды добавлена в белый список для него в /etc/upstart-xsessions, обработанный /etc/X11/Xsession.d/00upstart. KDM позволяет устанавливать Настольную среду 'Значение по умолчанию' (default в ~/.dmrc), эффективно kde-plasma, но не появление kde-plasma.
С Session=kde-plasma:
⟫ echo $DESKTOP_SESSION
kde-plasma
С Session=default в рабочем столе KDE Plasma:
⟫ echo $DESKTOP_SESSION
default
Это просто неправильный. И можно предположить теперь, почему это приводит проверку белого списка к сбою по сравнению с /etc/upstart-xsessions.
Быстрое исправление для выполнения терминального сеанса
killall gnome-keyring-daemon && eval `ssh-agent`
Заключение
Кажется, что можно поразить ошибку всеми Новомодными заданиями сессии, не запускаемыми вообще. Другая ошибка предотвращает надлежащее взаимодействие через интерфейс с брелоком для ключей GNOME агент SSH (или ssh-add должен жаловаться и перестать работать). О, я ненавижу Вас, ошибки.
После того как я нахожу время, чтобы проводить некоторое исследование на том, что, как точно предполагается, делает то, что, я зарегистрирую отчеты об ошибках.
На данный момент я решил просто 'использовать' Новомодную ошибку и препятствовать тому, чтобы Новомодные задания сессии работали путем установки Session=default. Я не уверен, сколько это повреждает, но до сих пор я не видел, что что-либо разваливается.
Первопричиной является появление брелока для ключей GNOME во-первых и который не должен лгать мне и продолжать предлагать неправильные ключи.