¿Cuál es la mejor manera de almacenar una contraseña svn cifrada en Ubuntu Server?

Hola

Tengo Ubuntu Server ejecutando un servidor de subversión. Estoy ejecutando el cliente en la misma máquina a través de SSH, y me gustaría que el cliente svn recuerde mi contraseña, pero no la almacene como texto sin formato. Mirando aquí veo dos métodos: gnome-keyring y kwallet. Como no estoy usando un administrador de escritorio, soy un poco cauteloso al intentar usar uno de estos. ¿Alguna sugerencia? ¿Estaría bien (o incluso funcionaría) usar una de las dos aplicaciones que mencioné?

TIA

— Andy
fuente

Puede ejecutar Gnome-keyring o Kwallet en la máquina remota. Cada uno viene en dos componentes, un demonio y una GUI.
- Puede ejecutar la aplicación GUI en la máquina remota si ejecuta ssh con reenvío X. El hecho de que sea una máquina "servidor" no significa que no pueda instalar aplicaciones GUI en ella. No importa si está ejecutando el entorno de escritorio correspondiente o no, las aplicaciones no necesitan un entorno de escritorio específico para ejecutarse.
- Puede controlar Kwallet en la línea de comando qdbus, aunque no es una buena idea en este caso específico porque tendría que escribir su contraseña en texto sin cifrar en una línea de comando, y otros usuarios pueden hacerlo. Ver también esta respuesta SU .
- Hay un enlace de python para Gnome-keyring y Kwallet (paquetes python-keyring-gnomey python-keyring-kwallet); podrías escribir un pequeño script de python para controlarlos. De hecho, ya hay uno para Gnome-keyring: gkeyring .
- Si su contraseña de llavero es la misma que su contraseña de inicio de sesión, puede instalarla libpam-keyringy su llavero se desbloqueará automáticamente cuando inicie sesión. Sin embargo, esto requiere iniciar sesión con una contraseña en lugar de un par de claves.
Si está ejecutando Gnome-keyring o Kwallet localmente, puede reenviarlos a través de ssh, con un poco de trabajo. Utilizan sockets Unix, que ssh no puede reenviar. Pero puede usar socatretransmitir los sockets Unix a los sockets TCP localmente y viceversa en la máquina remota:
```
while true; do socat TCP-LISTEN:22007 UNIX-CONNECT:"$GNOME_KEYRING_SOCKET"; done &
ssh -R22007:localhost:22007 remote.example.com
export GNOME_KEYRING_SOCKET="$HOME/.gnome-keyring-socket"
while true; do socat UNIX-LISTEN:"$GNOME_KEYRING_SOCKET" TCP4:localhost:22007; done &
```
Esto se puede automatizar con pequeños scripts de shell en cada lado y una RemoteForwardlínea de entrada ~/.ssh/config. En teoría, debería poder acceder al llavero de gnomo desde la máquina remota. Sin embargo, intenté acceder a él con caballito de mar, y ni siquiera intentó conectarse $GNOME_KEYRING_SOCKET; No sé por qué, y no sé si svn podría acceder al llavero.
Puede almacenar su contraseña svn en un sistema de archivos cifrado. Hay varias opciones ; Creo que la forma más sencilla de empezar es encfs. Configuración inicial:
```
sudo aptitude install encfs
encfs ~/.passwords.encrypted ~/.passwords
mv ~/.subversion/auth ~/.passwords/svn-auth
ln -s ../.passwords/svn-auth ~/.subversion/auth
```
Flujo de trabajo normal:
```
encfs ~/.passwords.encrypted ~/.passwords
... work ...
fusermount -u ~/.passwords
```
Este método tiene mi preferencia por varias razones:
- Tanto la configuración inicial como el flujo de trabajo normal son muy simples.
- No importa desde dónde inicie sesión, en particular, no necesita tener un servidor X local y usar el reenvío X sobre ssh.
- Un sistema de archivos cifrado es más versátil que un llavero (aunque es menos conveniente para el uso del llavero, pero en el caso de svn eso no importa).
- La única herramienta no ubicua que necesita es encfs (que requiere FUSE), y está empaquetada para Ubuntu.

— Gilles 'SO- deja de ser malvado'
fuente

Más de lo que podría haber esperado en una respuesta, ¡gracias! Probaré el tercer enfoque e informaré.

— Andy

Muy completa respuesta.

— this.josh

¿Es posible hacer un rescate de subversión si ~ / .subversion / auth está vacío / inexistente? De lo contrario, el tercer enfoque es un poco peligroso si olvida ejecutar encfs primero.

— martilleo

@unhammer Con este enfoque, si el sistema de archivos encfs no está montado, entonces ~/.subversion/authhay un enlace simbólico colgante. En ese caso, la subversión le dice que almacenará su contraseña (si no ha desactivado esa notificación) pero que de hecho no la almacena en ningún lugar (probado con svn 1.6.6). Por lo tanto, no hay riesgo con el tercer enfoque.

— Gilles 'SO- deja de ser malvado'

AHA, intentó por primera vez sin el enlace simbólico, pero ahora veo un enlace simbólico a una carpeta dentro de la carpeta cifrada funciona, gracias por aclarar eso :-)

— unhammer

gpg encripta un archivo con la contraseña, pero necesitarás una frase de contraseña para eso (¡y no pierdas la clave privada!).

Supongo que podría ingresar a svn la clave privada y también necesitará la frase de contraseña para usarla, pero toda esta configuración parece un poco extraña.

¿Por qué necesitas hacer esto?

— Sirex
fuente

No estoy buscando una forma de cifrado de uso general, sino una forma que se conecte bien con SVN. Cuando he usado SVN en Ubuntu Dekstop no ha habido un problema, así que supongo que ha estado usando gnome-keyring. Supongo nuevamente que gnome-keyring no está instalado en el servidor Ubuntu, y por eso está el problema. Actualmente puedo registrar cosas, pero recibo una advertencia de que solo puedo almacenar la contraseña sin cifrar. Vea el enlace que le di para más detalles. Gracias.

— Andy

He aclarado la explicación anterior, hth.

— Andy

Me encantaría usar ~ / .authinfo.gpg con el formato netrc estándar para SVN, y hacer que gpg maneje el cifrado, pero desafortunadamente parece que requeriría un poco más de configuración que la solución encfs. No parece que svn permita almacenes arbitrarios de contraseñas definidas por el usuario.

— Martillo