uso di gnome-keyring-daemon senza X


25

Mi chiedo se è possibile usare gnome-keyring-daemon senza X. Normalmente presenterà un prompt grafico per acquisire una password per il keyring; C'è un modo per aggirare questo? Mi piacerebbe poter usare Ubuntu One senza dover avviare una sessione grafica e digitare la mia password.

Risposte:


11

È possibile utilizzare pam_gnome_keyring.soper 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.)


Il secondo caso è il caso nel mio caso. Quell'opzione (non documentata?) --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.
intuito

1
err .. nevermind, è documentato da gnome-keyring-daemon --help. Ho appena controllato la manpage e / usr / share / doc.
intuito

2
@intuited: Bene, allora fai qualcosa del genere: read -rsp "Password: " pass; echo -n "$pass" | gnome-keyring-daemon --loginin una sceneggiatura.
gravità

In realtà sì, avrebbe funzionato; Stavo dimenticando che l'eco era un elemento incorporato.
intuito

In risposta al vecchio commento di @intuited: gnome-keyring-daemon --helpmi dà una buona panoramica, ma man gnome-keyring-daemoncontiene solo una breve descrizione del programma stesso ma senza argomenti.
feeela,

10

Sinossi

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

sfondo

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:

Materiale di origine

http://support.wandisco.com/index.php?/Knowledgebase/Article/View/362/17/how-to-setup-encrypted-svn-password-storage-using-gnome-keyring-in-an-ssh -sessione

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.


Grazie mille per questo, mi sono strappato i capelli cercando di sbarazzarmi di un errore "CRITICO **: Errore di comunicazione con gnome-keyring-daemon" su git pull. Le tue modifiche a ~ / .profile e ~ / .bash_logout hanno risolto il problema ... Continuo a non salvare le password ma sono un passo avanti! (Ubuntu 16.04.1 LTS)
Chris B,

1

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.


0

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!


Questo ha aiutato ad avvicinarmi di più a mysql-workbench all'interno di un contenitore docker ed esportare il display sul mio host mac. Quando provo ad aggiungere una password a una nuova connessione, mi viene mostrato il prompt, ma dopo aver digitato pwd, ottengo: "Impossibile eseguire il programma org.freedesktop.secrets: Operazione non consentita". Qualche indizio?
Ricardo Pesciotta,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.