Manejo automático de sesiones SSH en ChromeOS / Crostini

Una de las ventajas de usar Windows y macOS es la fácil administración de las llaves para utilizar conexiones seguras por medio del protocolo SSH. Por un lado la mayoría de los usuarios en Windows usan (¿usaban?) putty y en macOS probablemente OpenSSH directamente. Incluso en Linux utilizar SSH es bastante simple

Y dado que tengamos las configuraciones apropiadas, en cualquiera de los 3 principales sistemas operativos, es bastante fácil administrar nuestras llaves para conectarnos a algún servidor o bien utilizarlo como autenticación para varios servicios, el más común claro, el administrador de control de versiones GIT.

OpenSSH generalmente se compone de tres partes básicas:

1. El propio programa o binario para conexiones ssh
2. El administrador de llaves o «agent» llamado ssh-agent
3. Las propias librerias que utilizan aplicaciones «enlazadas» a este (como GIT)

Linux

Por ejemplo, me parece que Linux es, irónicamente, el sistema operativo que más facilita la administración de llaves. Aunque tengo años que no uso KDE (u otro entorno gráfico) en Gnome que es el default en la mayoría de las distribuciones, como Ubuntu (que es lo que uso actualmente, aunque prefiera Fedora, pero eso es para otro post), si tenemos nuestras llaves de SSH y queremos por ejemplo, actualizar alguna rama de GIT de un repositorio que está configurado para autenticarse por medio de SSH, se nos pide nuestra clave personal de la cuenta para «desbloquear» dicha llave, aun cuando tenga una contraseña o passphrase. Esto es administrado automáticamente por el manejador de llaves integrado de Gnome; «Seahorse«

Una vez que se ha desbloqueado la llave no se nos volverá a pedir hasta que volvamos a iniciar sesión en el sistema. Incluso se puede configurar para que no se nos pida la contraseña de la llave privada sino que se desbloquee automáticamente cada vez que iniciemos sesión, es decir, ya con iniciando sesión en el sistema, hacer un git pull o conectarnos por SSH a algún servidor no va a requerir la contraseña de la llave nunca.

En realidad no hace falta tener nada en particular configurado, solo nuestra llave pública y privada en los folders que por convención se usan, es decir en ~/.ssh respectivamente:

/home/gustavo/.ssh/id_rsa.pub
/home/gustavo/.ssh/id_rsa

macOS

En el sistema operativo de Apple pasa algo similar. Aunque en este caso se nos pide al menos una vez la contraseña, posterior a ello ya solo hay que estar dentro del sistema:

De hecho se puede configurar SSH para que utilice el administrador de llaves automáticamente también, de manera que si iniciamos sesión, las contraseñas de estas llaves se desbloquean automáticamente. Para ello primero debemos agregar la llave al agente:

ssh-add -K ~/.ssh/id_rsa

Una vez que hemos agregado la llave simplemente indicamos en el archivo de configuración de SSH que deseamos usar el administrador de llaves o el «Keychain» para desbloquear las llaves:

 Host *
   UseKeychain yes
   AddKeysToAgent yes
   IdentityFile ~/.ssh/id_rsa

Esto dentro del archivo de configuración que en mi caso sería /Users/vbox/.ssh/config dado que el usuario es vbox.

Windows 10

Como comenté hay muchos usuarios de windows que están acostumbrados a usar Putty, sin embargo, con la llegada de WSL (Windows Subsystem for Linux) y/o el uso de Windows Terminal y Powershell ahora es más fácil utilizar herramientas propias de Unix en este sistema operativo.

El proceso en este caso es similar a macOS. Aunque antes hay que habilitar el agente de SSH que por default no está activado. Esto lo podemos hacer desde PowerShell con los siguiente comandos:

# Instalación de OpenSSH si no se tiene instalado aun
Add-WindowsCapability -Online -Name openssh.client

# Habilitar el inicio del agente de SSH
Get-Service -Name ssh-agent | Set-Service -StartupType Automatic

# Iniciar el servicio del agente de SSH
Start-Service ssh-agent

Cabe destacar que los comandos deben ser ejecutados desde una terminal como administrador. El siguiente y último paso es agregar nuestra llave al agente:

ssh-add C:\Users\gustavo\.ssh\id_rsa

Una vez que hemos configurado el agente para que inicie automáticamente y hayamos agregado la llave a este, al conectarnos por protocolo SSH se utilizará la autenticación del sistema operativo para desbloquear la llave privada:

ChromeOS / Crostini

Pero, ¿Qué pasa con nosotros los raros que utilizamos una chromebook con ChromeOS? Mi última laptop personal fue una Dell con Linux y aunque amo el sistema operativo del pingüino decidí darle una nueva oportunidad a una chromebook ya que con la llegada de Crostini, me permitiría utilizarla no solo como equipo de entretenimiento o para revisar correos y cosas más triviales cuando estuviera fuera de casa sino que además podría realizar mis tareas de desarrollo si lo necesitase.

La verdad es que mi Pixelbook ha sido probablemente la mejor laptop que he tenido en toda mi historia con computadoras; es bonita, con materiales de primera calidad, rápida pero sobre todo el ecosistema de ChromeOS permite que sea un equipo de «usar y olvidarse» es decir, cero configuración y dolores de cabeza. Tanto así que es el equipo/sistema de facto ya en instituciones educativas de educación primaria y media superior en EUA.

El gran potencial es que para usuarios avanzados como yo, es poder habilitar una máquina virtual de Linux dentro de esta (Crostini) que por default es una versión de Debian Buster, es decir, la versión 10 estable.

El gran inconveniente para mi es que cuando estoy trabajando en una misma sesión desde la terminal de chromeos es muy molesto tener que estar introduciendo una y otra vez la clave de la llave privada cuando necesito «jalar» o «empujar» cambios en GIT que es muy a menudo.

Desafortunadamente, Crostini se ejecuta como un sistema operativo «headless» lo cual quiere decir que no hay un agente «corriendo» en segundo plano como Seahorse en el caso de Ubuntu/Gnome.

Pero resolver esto de hecho es bastante fácil. Con una herramienta llamada keychain es posible administrar de la misma manera nuestras llaves protegidas por contraseñas en un entorno donde no contamos con un administrador gráfico de estas.

El primer paso es instalar dicho paquete, en una terminal ejecutamos:

sudo apt install keychain

Si todo salió bien deberíamos ya tener el paquete instalado y configurado:

Una vez instalado solo debemos agregar un pequeño script a nuestro ~/.bashrc para que se ejecute esta herramienta cada que iniciemos sesión:

# auto SSH key management
eval `keychain --agents ssh --eval id_rsa`

Cerramos la terminal y al volver a abrirla/ejecutarla nos mostrará lo siguiente:

Como vemos nos indica «Starting ssh-agent» que significa que el agente no estaba corriendo en segundo plano, una vez ejecutado, agregará la llave y nos pedirá la contraseña de esta para desbloquearla:

Después de esto ya podemos iniciar conexiones o hacer uso de GIT por medio de SSH sin tener que estar introduciendo una y otra vez la contraseña de dicha llave:

Si abrimos otra pestaña por ejemplo, notaremos el siguiente mensaje:

Si ponemos atención, veremos que parte del mensaje es que se encontró una sesión existente del agente de SSH (644 es el PID o process ID) por lo cual ya no se nos pide la contraseña de la llave privada.

¿Pero, no es esto de alguna manera inseguro?

Claro, todo depende siempre del uso que se le den a las cosas. Keychain cuenta con una opción extra que nos permite re-utilizar la contraseña de la llave solo en la actual sesión, es decir, en el momento que cerremos la terminal o si abrimos otra pestaña, se nos volverá a pedir dicha contraseña para cada sesión, para habilitar dicha opción simplemente agregamos el argumento --clear al script que agregamos a nuestro ~/.bashrc de la siguiente manera:

# auto SSH key management
eval `keychain --agents ssh --clear --eval id_rsa`

Ahora, al iniciar una nueva pestaña por ejemplo, se nos pedirá de nuevo nuestra contraseña:

Como se ve en la imagen, aunque se encontró un agente ejecutandose en segundo plano, se nos pide de nuevo la contraseña, aunque una vez que la introducimos en esa pestaña, se mantendrá en memoria, es decir, esto solo aplica para nuevas sesiones.

Espero este pequeño tutorial les haya sido de utilidad a aquellos desarrolladores que utilizan ChromeOS que aunque somos pocos vamos en aumento.