Risposte:
È possibile utilizzare pam_gnome_keyring.so
per avviare e sbloccare il demone. GDM lo fa già; per login
, è necessario configurarlo manualmente.
Aggiungi queste righe a /etc/pam.d/login
:
auth opzionale pam_gnome_keyring.so sessione opzionale pam_gnome_keyring.so auto_start
Se accedi senza password (SSH con Kerberos o chiavi pubbliche), potrebbe funzionare: (non l'ho provato)
echo -n "mypassword" | gnome-keyring-daemon --login
(È ancora necessario che il demone sia in esecuzione - avviato tramite PAM o con --daemonize
.)
gnome-keyring-daemon --help
. Ho appena controllato la manpage e / usr / share / doc.
read -rsp "Password: " pass; echo -n "$pass" | gnome-keyring-daemon --login
in una sceneggiatura.
gnome-keyring-daemon --help
mi dà una buona panoramica, ma man gnome-keyring-daemon
contiene solo una breve descrizione del programma stesso ma senza argomenti.
I lavori necessari per l'installazione di svn con supporto keyring e l'installazione dell'applicazione Collabnet keyring_tool sono già eseguiti per i nostri server Linux.
1) Configurare il client SVN per utilizzare il keyring:
1.1) Modifica ~ / .subversion / config
[auth]
password-stores = gnome-keyring
1.2) Modifica ~ / .subversion / server
[global]
store-passwords = yes
store-plaintext-passwords = no
2) Crea un portachiavi per la tua password. Ti verrà richiesto di creare una nuova password per sbloccare il portachiavi; questo può essere quello che desideri:
keyring_tool --create=svn
3) Imposta il nuovo portachiavi come predefinito:
keyring_tool --setdef=svn
4) In .bash_profile o .bash_login (supponendo che tu stia usando bash come terminale)
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
Ho riscontrato un problema simile durante il tentativo di stabilire un modo senza problemi per garantire l'accesso degli utenti autorizzati a determinati repository SVN sul luogo di lavoro. Fondamentalmente abbiamo dovuto forzare il controllo delle credenziali ogni volta che un utente accede al server, quindi anche il comando svn update richiederebbe l'autenticazione. L'archiviazione delle password in chiaro è stata rilasciata, quindi con una piccola ricerca ho scoperto che usando il keyring gnome per aggirare la nostra base di utenti con richieste di autenticazione costanti, pur mantenendo gli utenti non autorizzati fuori dai repository, non dovrebbero avere accesso alla visualizzazione.
Gran parte del nostro lavoro quotidiano viene svolto tramite tunnel ssh in un server RedHat senza supporto X, quindi ho dovuto trovare un modo per aggirare il supporto X11. Dopo alcune ricerche sono riuscito a trovare il modo di aggirarlo qui:
La chiave qui sta usando Collabnet keyring_tool per creare un portachiavi senza il client gnome-keyring-manager e stabilire da soli il dbus-launch anziché lasciare che SVN gestisca il setup. SVN utilizza DBUS per connettersi al demone gnome-keyring e influire sull'autenticazione generale. Avviando e abbattendo manualmente la sessione dbus con la sintassi -sh si evita di provare a connettersi a un client X all'avvio di dbus. Se avvii semplicemente il demone gnome-keyring e provi a usare SVN, ti verrà comunque richiesto di inserire la password del tuo portachiavi, ma anche le tue credenziali SVN. Il dbus fallirà quando SVN tenta di avviarlo a causa della mancanza di un client X; apparentemente SVN non usa alcun flag speciale all'avvio del dbus.
Innanzitutto, quello che vuoi davvero fare è eseguire Ubuntu One rigorosamente dalla riga di comando. Dai un'occhiata alle FAQ di Ubuntu One . Le FAQ dicono che al momento non è possibile, ma ci sono alcuni strumenti della CLI come u1sdtool e u1sync . C'è anche una serie di FAQ su Ubuntu One su Launchpad; il contenuto potrebbe essere lo stesso del precedente link wiki.ubuntu.com.
Per quanto riguarda la tua vera domanda su gnome-keyring-daemon , le FAQ suggeriscono (1) l'impostazione di auto-login e (2) la sincronizzazione della password del tuo portachiavi con la tua password di accesso. Questo (in teoria) di evitare pronta la password, ma avrebbe bisogno di almeno una base X-session per essere in esecuzione.
C'è un bug / lista dei desideri di Ubuntu One su Launchpad che richiede di semplificare la gestione dei sistemi senza testa. Apparentemente la compilazione dal sorgente è consigliata per un'installazione leggera (per evitare la necessità di tutte le librerie della GUI e simili). Questo commento è vecchio, ma particolarmente interessante:
Il problema è che usiamo python-gnomekeyring. Per noi per supportare senza testa, dovremo passare al portachiavi in pitone e gestire la memorizzazione dei token in un posto diverso dal portachiavi di gnome su schermi senza testa. Tuttavia, nulla di tutto ciò accadrà per l'imballaggio Karmic poiché è congelato e questo cambiamento non sarebbe accettabile in una SRU.
Per Lucid, dovremmo avere un servizio di autenticazione più solido, che dovrebbe consentirci di supportare meglio i display senza testa.
Non so dire se questo "servizio di autenticazione più solido" sia stato effettivamente realizzato per Lucid; in base alle dipendenze dei pacchetti, sembra che il client Ubuntu One sia ancora dipendente da python-gnomekeyring.
Ho avuto un certo successo nel far funzionare mysql-workbench con gnome-keyring in una sessione SSH inoltrata x. Questo era un account che utilizzava l'autenticazione con chiave pubblica (nessuna password).
Ho usato dbus-run-session per raggiungere questo obiettivo una volta connesso alla sessione ssh:
dbus-run-session bash -c 'GNOME_KEYRING_CONTROL=1 mysql-workbench --verbose'
speriamo che queste informazioni siano utili a qualcuno!
--login
È piuttosto utile, anche se sicuramente non vorrei mantenere la mia password non cancellata in uno script o metterla su una riga di comando. la lettura in modalità non protetta dall'interno di uno script (non shell-language) che quindi trasmette l'input al demone generato sarebbe probabilmente un buon modo per farlo. Dovrei iniziare questo processo una sola volta per avvio, quindi ha senso digitare la password; Devo solo essere in grado di farlo dalla riga di comando anziché tramite la finestra di dialogo GTK.