Ich frage mich, ob es möglich ist, gnome-keyring-daemon ohne X zu verwenden. Normalerweise wird eine grafische Eingabeaufforderung angezeigt, um ein Kennwort für den Schlüsselbund zu erhalten. Gibt es einen Weg, dies zu umgehen? Ich möchte ubuntu one verwenden können, ohne eine grafische Sitzung zu starten und mein Passwort einzugeben.
Antworten:
Mit können Sie pam_gnome_keyring.soden Daemon starten und entsperren. GDM macht das schon; Für loginmüssen Sie es manuell konfigurieren.
Fügen Sie diese Zeilen hinzu zu /etc/pam.d/login:
auth optional pam_gnome_keyring.so session optional pam_gnome_keyring.so auto_start
Wenn Sie sich ohne Kennwort anmelden (SSH mit Kerberos oder öffentlichen Schlüsseln), funktioniert dies möglicherweise : (Ich habe es nicht getestet.)
echo -n "mypassword" | gnome-keyring-daemon --login
(Der Daemon muss noch laufen - entweder über PAM oder mit --daemonize.)
gnome-keyring-daemon --help. Ich habe gerade die Manpage und / usr / share / doc überprüft.
read -rsp "Password: " pass; echo -n "$pass" | gnome-keyring-daemon --loginin einem Skript.
gnome-keyring-daemon --helpgibt mir einen guten Überblick, man gnome-keyring-daemonenthält aber nur eine kurze Beschreibung des Programms selbst aber keine Argumente.
Die für die Installation von svn mit Schlüsselringunterstützung und die Installation der Collabnet-Anwendung keyring_tool erforderlichen Aufgaben werden bereits für unsere Linux-Server ausgeführt.
1) Konfigurieren Sie den SVN-Client für die Verwendung des Schlüsselbunds:
1.1) Bearbeiten Sie ~ / .subversion / config
[auth]
password-stores = gnome-keyring
1.2) Bearbeiten Sie ~ / .subversion / servers
[global]
store-passwords = yes
store-plaintext-passwords = no
2) Erstellen Sie einen Schlüsselring für Ihr Passwort. Sie werden aufgefordert, ein neues Kennwort zu erstellen, um den Schlüsselring zu entsperren. Dies kann alles sein, was Sie wünschen:
keyring_tool --create=svn
3) Legen Sie den neuen Schlüsselring als Standard fest:
keyring_tool --setdef=svn
4) In .bash_profile oder .bash_login (vorausgesetzt, Sie verwenden bash als Terminal)
if [ -e /usr/bin/gnome-keyring-daemon ]; then
if [ ! -z "`kill -0 $GNOME_KEYRING_PID 2>&1`" ]; then
# Create dbus transport link for SVN to talk to the keyring.
eval `dbus-launch --sh-syntax`
# Start the keyring daemon.
# The use of export here captures the GNOME_KEYRING_PID, GNOME_KEYRING_SOCK
# env values echoed out at startup.
export `/usr/bin/gnome-keyring-daemon`
fi
fi
5) In .bash_logout
# Kill the message bus established for SVN / Keyring communication
if [ ! -z "`kill -0 $DBUS_SESSION_BUS_PID 2>&1`" ]; then
kill $DBUS_SESSION_BUS_PID > /dev/null 2>&1
fi
# Kill the Gnome Keyring Daemon prior to logout.
if [ ! -z "`kill -0 $GNOME_KEYRING_PID 2>&1`" ]; then
kill $GNOME_KEYRING_PID > /dev/null 2>&1
fi
Ich bin auf ein ähnliches Problem gestoßen, als ich versucht habe, einen problemlosen Weg zu finden, um autorisierten Benutzern den Zugriff auf bestimmte SVN-Repos bei der Arbeit zu ermöglichen. Grundsätzlich mussten wir die Überprüfung der Anmeldeinformationen jedes Mal erzwingen, wenn ein Benutzer auf den Server zugreift, damit selbst der Befehl svn update eine Authentifizierung erfordert. Da die Speicherung von Klartext-Passwörtern nicht mehr möglich war, konnte ich mit ein wenig Nachforschungen den Gnome-Schlüsselbund verwenden, um unsere Benutzerbasis mit ständigen Authentifizierungsanfragen zu belästigen und gleichzeitig zu verhindern, dass nicht autorisierte Benutzer Zugriff auf Repositorys haben, auf die sie keinen Zugriff haben sollten.
Ein Großteil unserer täglichen Arbeit wird über SSH-Tunnel auf einem RedHat-Server ohne X-Unterstützung erledigt, sodass ich einen Weg finden musste, um die X11-Unterstützung zu umgehen. Nach einigem Suchen habe ich es hier geschafft, mich zurechtzufinden:
Der Schlüssel hierfür ist die Verwendung des Collabnet-Tools keyring_tool, um einen Schlüsselring ohne den Gnome-Keyring-Manager-Client zu erstellen und den dbus-Start selbst durchzuführen, anstatt SVN die Einrichtung zu überlassen. SVN verwendet DBUS, um eine Verbindung zum Gnome-Keyring-Daemon herzustellen und die Gesamtauthentifizierung zu beeinflussen. Indem Sie die dbus-Sitzung manuell mit der Syntax -sh starten und beenden, vermeiden Sie den Versuch, beim Start von dbus eine Verbindung zu einem X-Client herzustellen. Wenn Sie nur den gnome-keyring-daemon starten und versuchen, SVN zu verwenden, werden Sie weiterhin zur Eingabe Ihres Schlüsselbundkennworts aufgefordert. Anschließend werden Sie jedoch auch zur Eingabe Ihrer SVN-Anmeldeinformationen aufgefordert. Der dbus schlägt fehl, wenn SVN versucht, ihn zu starten, weil ein X-Client fehlt. anscheinend verwendet SVN keine speziellen Flags, wenn der dbus gestartet wird.
Zunächst möchten Sie Ubuntu One ausschließlich über die Befehlszeile ausführen. Schauen Sie sich die Ubuntu One FAQ an . Die FAQ besagen, dass dies derzeit nicht möglich ist, aber es gibt einige CLI-Tools wie u1sdtool und u1sync . Es gibt auch eine Reihe von FAQs zu Ubuntu One im Launchpad. Der Inhalt entspricht möglicherweise dem früheren Link auf wiki.ubuntu.com.
In Bezug auf Ihre aktuelle Frage zu gnome-keyring-daemon wird in den häufig gestellten Fragen vorgeschlagen , (1) die automatische Anmeldung festzulegen und (2) Ihr Schlüsselbundkennwort mit Ihrem Anmeldekennwort zu synchronisieren. Dies würde (theoretisch) die Passwortabfrage vermeiden, aber es würde mindestens eine grundlegende X-Sitzung erfordern, um ausgeführt zu werden.
Es gibt einen Fehler / eine Wunschliste für Ubuntu One auf dem Launchpad, der / die den Umgang mit Headless-Systemen erleichtert. Offensichtlich wird für eine einfache Installation das Erstellen aus dem Quellcode empfohlen (um zu vermeiden, dass alle GUI-Bibliotheken und dergleichen benötigt werden). Dieser Kommentar ist alt, aber besonders interessant:
Das Problem ist, dass wir Python-Gnomekeyring verwenden. Damit wir Headless unterstützen können, müssen wir zum Python-Schlüsselbund wechseln und die Speicherung von Tokens an einem anderen Ort als dem Gnom-Schlüsselbund auf Headless-Displays vornehmen. Nichts davon wird jedoch für die Karmic-Verpackung passieren, da diese eingefroren ist, und diese Änderung wäre in einer SRU nicht akzeptabel.
Für Lucid sollten wir einen robusteren Authentifizierungsdienst haben, der es uns ermöglichen sollte, Headless-Displays besser zu unterstützen.
Ich kann nicht sagen, ob dieser "robustere Authentifizierungsdienst" tatsächlich für Lucid eingerichtet wurde. Aufgrund der Paketabhängigkeiten scheint der Ubuntu One-Client immer noch von python-gnomekeyring abhängig zu sein.
Ich hatte einige Erfolge damit, dass mysql-workbench in einer x-forwarded-SSH-Sitzung mit gnome-keyring funktioniert. Hierbei handelt es sich um ein Konto, für das die öffentliche Authentifizierung verwendet wurde (kein Kennwort).
Ich habe dbus-run-session verwendet, um dies zu erreichen, nachdem ich mit der ssh-Session verbunden war:
dbus-run-session bash -c 'GNOME_KEYRING_CONTROL=1 mysql-workbench --verbose'
hoffentlich sind diese Informationen für jemanden nützlich!
--loginOption ist ziemlich nützlich, obwohl ich mein nicht gehashtes Passwort sicher nicht in einem Skript behalten oder in eine Befehlszeile schreiben möchte. Das Lesen im ungeprüften Modus in einem Skript (das keine Shell-Sprache ist), das diese Eingabe dann an den gespawnten Daemon weiterleitet, ist wahrscheinlich eine gute Möglichkeit, dies zu tun. Ich sollte diesen Prozess nur einmal pro Start starten müssen, daher ist es sinnvoll, das Kennwort einzugeben. Ich muss nur in der Lage sein, dies über die Befehlszeile zu tun, anstatt über den GTK-Dialog.