uso de gnome-keyring-daemon sin X


25

Me pregunto si es posible usar gnome-keyring-daemon sin X. Normalmente presentará un mensaje gráfico para adquirir una contraseña para el llavero; ¿Hay alguna forma de evitar esto? Me gustaría poder usar ubuntu one sin tener que iniciar una sesión gráfica y escribir mi contraseña.

Respuestas:


11

Puedes usar pam_gnome_keyring.sopara iniciar y desbloquear el demonio. GDM ya hace esto; para login, debe configurarlo manualmente.

Agregue estas líneas a /etc/pam.d/login:

auth opcional pam_gnome_keyring.so
sesión opcional pam_gnome_keyring.so auto_start

Si inicia sesión sin contraseña (SSH con Kerberos o claves públicas), esto puede funcionar: (No lo he probado)

echo -n "mypassword" | gnome-keyring-daemon --login

(Todavía necesita que el demonio se esté ejecutando, ya sea iniciado a través de PAM o con --daemonize).


El segundo caso es el caso en mi caso. Esa --loginopción (¿indocumentada?) Es bastante útil, aunque estoy seguro de que no quisiera mantener mi contraseña sin compartir en un script o ponerla en una línea de comando. leer en modo no grabado desde un script (sin lenguaje de shell) que luego pasa esa entrada al demonio generado probablemente sea una buena manera de hacerlo. Solo debería tener que iniciar este proceso una vez por arranque, por lo que tiene sentido escribir la contraseña; Solo necesito poder hacerlo en la línea de comando en lugar de hacerlo a través del diálogo GTK.
intuido

1
err .. no importa, está documentado por gnome-keyring-daemon --help. Acabo de revisar la página de manual y / usr / share / doc.
intuido

2
@intuited: Bueno, entonces haz algo como esto: read -rsp "Password: " pass; echo -n "$pass" | gnome-keyring-daemon --loginen un script.
Grawity

En realidad sí, eso funcionaría; Me estaba olvidando de que el eco estaba incorporado.
intuido

En respuesta al antiguo comentario de @intuited: gnome-keyring-daemon --helpme da una buena descripción general, pero man gnome-keyring-daemonsolo contiene una breve descripción del programa en sí, pero sin argumentos.
feeela

10

Sinopsis

Los trabajos necesarios para instalar svn con soporte de llavero e instalar la aplicación Collabnet keyring_tool ya se han realizado para nuestros servidores Linux.

1) Configure el cliente SVN para usar llavero:

1.1) Editar ~ / .subversion / config

[auth]
password-stores = gnome-keyring

1.2) Editar ~ / .subversion / servidores

[global]
store-passwords = yes
store-plaintext-passwords = no

2) Crea un llavero para tu contraseña. Se le pedirá que cree una nueva contraseña para desbloquear el llavero; Esto puede ser lo que desee:

keyring_tool --create=svn

3) Establezca el nuevo llavero como predeterminado:

keyring_tool --setdef=svn

4) En .bash_profile o .bash_login (suponiendo que esté usando bash como su 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) En .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

Fondo

Me encontré con un problema similar al intentar establecer una forma libre de problemas para garantizar el acceso del usuario autorizado a ciertos repositorios SVN en el trabajo. Básicamente, tuvimos que forzar la verificación de credenciales cada vez que un usuario accede al servidor, por lo que incluso el comando svn update requeriría autenticación. Claramente, el almacenamiento de contraseñas de texto sin formato estaba fuera, así que con un poco de investigación encontré el uso del llavero gnome como una forma de hostigar a nuestra base de usuarios con solicitudes de autenticación constantes y al mismo tiempo mantener a los usuarios no autorizados fuera de los repositorios que no deberían tener acceso para ver.

Gran parte de nuestro trabajo diario se realiza a través de túneles ssh en un servidor RedHat sin soporte X, así que tuve que encontrar una forma de evitar el soporte X11. Después de un poco de búsqueda, logré encontrar el camino aquí:

Material de origen

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

La clave aquí es usar Collabnet keyring_tool para crear un llavero sin el cliente gnome-keyring-manager y establecer el dbus-launch usted mismo en lugar de permitir que SVN maneje la configuración. SVN usa DBUS para conectarse al gnome-keyring-daemon y afectar la autenticación general. Al iniciar y eliminar manualmente la sesión de dbus con -sh-syntax, evita intentar conectarse a un cliente X al iniciar dbus. Si solo inicia gnome-keyring-daemon e intenta usar SVN, aún le pedirá su contraseña de llavero, pero también le pedirá sus credenciales SVN. El dbus fallará cuando SVN intente iniciarlo debido a la falta de un cliente X; aparentemente SVN no usa ninguna bandera especial al iniciar el dbus.


Muchas gracias por esto, me han arrancado el pelo tratando de deshacerme de un error "CRÍTICO **: Error de comunicación con gnome-keyring-daemon" en git pull. Sus cambios a ~ / .profile y ~ / .bash_logout arreglaron eso ... ¡Todavía no guardo las contraseñas pero estoy un paso más cerca! (Ubuntu 16.04.1 LTS)
Chris B

1

Primero, lo que realmente quieres hacer es ejecutar Ubuntu One estrictamente desde la línea de comandos. Echa un vistazo a las preguntas frecuentes de Ubuntu One . Las preguntas frecuentes dicen que actualmente no es posible, pero hay algunas herramientas de CLI como u1sdtool y u1sync . También hay un conjunto de preguntas frecuentes sobre Ubuntu One en Launchpad; el contenido puede ser el mismo que el enlace anterior de wiki.ubuntu.com.

Con respecto a su pregunta real sobre gnome-keyring-daemon , las preguntas frecuentes sugieren (1) configurar el inicio de sesión automático y (2) sincronizar su contraseña de llavero con su contraseña de inicio de sesión. Esto (en teoría) evitar la pronta la contraseña, pero podría requerir al menos un básico X-sesión a estar en funcionamiento.

Hay una lista de errores / deseos de Ubuntu One en Launchpad que solicita que sea más fácil manejar sistemas sin cabeza. Aparentemente, se recomienda construir desde la fuente para una instalación ligera (para evitar la necesidad de todas las bibliotecas GUI y demás). Este comentario es antiguo, pero particularmente interesante:

El problema es que usamos python-gnomekeyring. Para que podamos admitir sin cabeza, tendremos que cambiar a python-keyring y manejar el almacenamiento de tokens en otro lugar que no sea gnome-keyring en pantallas sin cabeza. Sin embargo, nada de esto sucederá para el empaquetado kármico ya que está congelado, y este cambio no sería aceptable en una SRU.

Para Lucid, deberíamos tener un servicio de autenticación más robusto, que debería permitirnos admitir mejor las pantallas sin cabeza.

No puedo decir si este "servicio de autenticación más robusto" fue realmente implementado para Lucid; basado en las dependencias del paquete, parece que el cliente Ubuntu One todavía depende de python-gnomekeyring.


0

Tuve cierto éxito al hacer que mysql-workbench funcionara con gnome-keyring en una sesión SSH reenviada por x. Esta era una cuenta que utilizaba la autenticación de clave pública (sin contraseña).

Usé dbus-run-session para lograr esto una vez conectado a la sesión ssh:

dbus-run-session bash -c 'GNOME_KEYRING_CONTROL=1 mysql-workbench --verbose'

¡espero que esta información sea útil para alguien!


Esto ayudó un paso más cerca de hacer que mysql-workbench se ejecute dentro de un contenedor docker y exporte la pantalla a mi host de mac. Cuando intento agregar una contraseña a una nueva conexión, me muestra el mensaje, pero después de escribir pwd, aparece: "No se pudo ejecutar el programa org.freedesktop.secrets: operación no permitida". ¿Alguna pista?
Ricardo Pesciotta
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.