Ejecución de aplicaciones remotas

• Acceso mediante claves públicas
• Configuración general de SSH
• Problemas de la ejecución remota

Ahora que ya sentamos las bases e interconectamos los dos ordenadores pasemos a la ejecución de aplicaciones remotas (es decir, en otro ordenador).

Para ejecutar aplicaciones remotas existen sistemas varios, como rsh, telnet o Secure Shell (SSH). El que se utilizará concretamente en este manual es SSH, cuyas principales ventajas frente a los otros son la seguridad y el poder redirigir los datos generados por el sistema X de ventanas (es decir, que las aplicaciones gráficas se abrirán en una ventana, igual que si las ejecutásemos en el propio ordenador y no en un ordenador remoto).

Para utilizar SSH se necesita una aplicación cliente y un servidor. El cliente SSH nos permitirá conectarnos a otro ordenador, en el que deberá haber un servidor SSH que atienda nuestras peticiones. Los paquetes openssh-clients y openssh-server contienen cliente y servidor respectivamente, y deberán ser instalados si no lo estuviesen ya.

Para que el servidor de SSH pueda atender peticiones correctamente, el cortafuegos del ordenador en que se ejecuta deberá permitir conexiones en el puerto 22. En el entorno de este manual, la interfaz de red del ordenador viejo y la interfaz de red del ordenador nuevo que conecta con el viejo no tienen cortafuegos protegiéndolas (por estar en una red local segura), así que ya podríamos conectarnos de uno a otro ordenador. Por ejemplo, para conectar desde el ordenador nuevo al viejo, en mi caso escribiría (como usuario):

ssh HAL9003

Me preguntaría la contraseña del usuario en HAL9003 (el ordenador viejo), y una vez introducida ya podría ejecutar aplicaciones del ordenador viejo desde el ordenador nuevo (y viéndolas en el ordenador nuevo, en el caso de que fuesen aplicaciones gráficas).

Acceso mediante claves públicas

No obstante, tener que meter la contraseña cada vez que entramos en el otro ordenador es un poco engorroso. Dado que estamos en una red local, y teóricamente segura... ¿no podemos evitar de alguna manera el poner contraseñas? Pues sí, se puede.

Pero si estás pensando en simplemente quitarle las contraseñas de entrada a todos los usuarios más te vale que ni siquiera lo intentes, o un pingüino y un ñu aparecerán a tu lado y te darán un tirón de orejas monumental.

Un detalle importantísimo es que el servidor de SSH escucha en todas las interfaces de red disponibles en el ordenador. Así que en nuestro ordenador nuevo (el conectado a Internet) no sólo escuchará las peticiones que vengan del ordenador viejo por la interfaz eth1, sino también las peticiones que le lleguen de Internet por la interfaz eth0.

Si le quitases las contraseñas a tus usuarios y el cortafuegos de la interfaz eth0 permitiese acceder al puerto de SSH las probabilidades de que te crackeasen el ordenador serían muy, pero que muy altas. Por muy seguro que sea GNU/Linux, si nos empeñamos en hacerlo vulnerable al final lo conseguiremos.

Y puede que estés pensando algo como "ni que fuese tonto, simplemente no abro el puerto y está". Yo también creía que no era tonto, pero al final resultó que no era tan listo como pensaba... Haciendo pruebas un día no me di cuenta y acabé con un usuario que sí tenía contraseña, pero trivial, y el puerto de SSH abierto en el cortafuegos. ¿Resultado? Entraron en dicho usuario desde Internet (posiblemente con un programa que pruebe cientos de nombres y contraseñas hasta que dé con una que sirve). De casualidad me di cuenta de que habían entrado y al final no pasó nada, pero pudo haber pasado.

Así que si a mí por un descuido me entraron en un usuario que incluso tenía contraseña, puedes figurarte que tener a tus usuarios sin contraseña es una mala política, incluso aunque ahora mismo creas que no vas a andar abriendo el puerto de SSH a Internet.

Vale, usuarios sin contraseñas idea pésima, entendido. Pero entonces, ¿cómo podemos acceder por SSH sin necesidad de teclear la contraseña?

Mediante el sistema de claves públicas y privadas.

La idea de la clave pública/privada es la siguiente. Utilizando ciertas funciones matemáticas se genera un par de claves. Una de ellas es pública y todo el mundo tiene acceso a ella. La otra es privada y sólo el propietario tiene acceso a ella. En el contexto de SSH, la clave pública está distribuida por todos los servidores SSH a los que te quieres conectar, y la privada la llevas contigo.

La particularidad de las claves es que si se cifra algo con la clave pública, sólo se puede descifrar con la clave privada. De este modo sólo quien posee la clave privada puede leer el contenido del mensaje. Si se cifra algo con la clave privada, todo el mundo puede descifrarlo con la clave pública. De este modo se puede saber que quien envió el mensaje es quien dice ser, ya que sólo esa persona podría haberlo cifrado así.

Cuando te conectas por SSH usando el sistema de claves el servidor SSH manda una pregunta cifrada con las claves públicas que conoce. Si tu cliente SSH tiene una clave privada que se corresponda con alguna de las claves públicas, descifra la pregunta, cifra la respuesta y la envía al servidor SSH (la pregunta/respuesta es cosa interna del SSH, no es que tengas que responder tú a nada ;) ).

Así que lo que tendremos que hacer es generar un par de claves pública y privada para el usuario en un ordenador, y copiar la clave pública en el otro ordenador. Como estamos en una red local segura, realmente copiaremos tanto la clave pública como la privada. Es decir, utilizaremos una única clave para entrar en el ordenador viejo desde el nuevo, y en el nuevo desde el viejo.

Para el siguiente conjunto de órdenes se supone que estamos en el ordenador nuevo.

Para empezar abrimos una terminal en un usuario y ejecutamos:

ssh-keygen -t dsa -b 1024

Hay que destacar que nos pedirá una frase de paso. Las claves privadas pueden protegerse si se desea con contraseña (la frase de paso es una contraseña larga, como una frase, de ahí su nombre) para dar una vuelta de tuerca más a la seguridad. En nuestro caso, nos interesa precisamente no poner ninguna contraseña a la clave privada para poder entrar sin teclearla.

Las claves creadas por defecto serán /home/nombreUsuario/.ssh/id_dsa en el caso de la clave privada y /home/nombreUsuario/.ssh/id_dsa.pub en el caso de la pública. Cuando utilizamos ssh para conectarnos a otro ordenador, éste utilizará la clave privada por defecto.

Si tenemos más de una clave privada, por ejemplo una sin contraseña para nuestra red local y otra con contraseña para ordenadores externos, lo más probable es que nos interese que la clave sin contraseña tenga el nombre por defecto, y que la clave con contraseña tenga un nombre distinto que indiquemos a SSH cuando tengamos que entrar en ordenadores externos (ssh nombreOrdenador -i ruta/Hasta/La/Clave). Pero cada cuál verá qué le conviene más ;)

Si ssh-keygen crea las claves con el nombre por defecto, las creará en el directorio .ssh, así como dicho directorio en el directorio personal del usuario si fuese necesario. Si creásemos nosotros mismos el directorio, los permisos pueden ser a lo sumo 755 (rwxr-xr-x), pero no más liberales (nada de escritura para grupo ni el resto, o no funcionará al ir a buscar las claves públicas autorizadas, en los logs dirá Authentication refused: bad ownership or modes for directory /home/nombreUsuario/.ssh).

Una vez creadas las claves con el nombre por defecto cambiamos al directorio .ssh:

cd /home/nombreUsuario/.ssh

Añadimos la clave pública a las llaves autorizadas para poder entrar desde el otro ordenador (los permisos del archivo authorized_keys, al igual que el directorio, deben ser a lo sumo 755, o se negará a buscar las claves autorizadas, guardando en los logs del sistema Authentication refused: bad ownership or modes for file /home/nombreUsuario/.ssh/authorized_keys):

cat id_dsa.pub >> authorized_keys && chmod 755 authorized_keys

Ahora subimos la clave pública y privada al usuario del ordenador viejo (porque, como ya se indicó, se usará una clave única en ambos ordenadores de la red local). Hay que crear el directorio .ssh previamente, ya que scp chilla si no está creado:

ssh HAL9003 'mkdir .ssh' && scp id_dsa id_dsa.pub HAL9003:.ssh && ssh HAL9003 'cat .ssh/id_dsa.pub >> .ssh/authorized_keys'

Nos pedirá la contraseña 3 veces (una por cada SSH y otra por scp)... pero será la última vez ;)

Finalmente, verificamos que las claves funcionan al conectarnos sin usar contraseña al viejo y desde éste al nuevo. Así que desde el ordenador nuevo entramos al viejo con:

ssh HAL9003

Y con la sesión abierta en el viejo, reentramos al nuevo:

ssh HAL9004

Repetimos la operación para cada usuario que queramos que pueda entrar de un ordenador a otro, y ya está :)

(Kudos a vfmmeo por su artículo original, Autenticándonos a servidores ssh con clave privada ;) )

Configuración general de SSH

Acabamos de ver que por un descuido tonto nuestro ordenador puede quedar comprometido en el salvaje y despiadado océano de Internet, y que es mejor llevar a cabo medidas preventivas en lugar de reactivas. O, en palabras del sabio refranero, más vale prevenir que curar.

¿Pero hay algo más que podamos hacer para que nuestro ordenador caiga presa de las garras de los infames crackers? ¿Y qué pasaría si quisiese abrir el puerto de SSH voluntariamente para poder conectarme desde otro lugar? ¿Acaso un servidor SSH expuesto a Internet está abocado al desastre? ¿Realmente iba un tipo dentro de R2-D2 cuando grabaron La guerra de las galaxias?

Aunque el panorama pintado anteriormente parece oscuro y aciago, lo cierto es que es perfectamente posible tener un servidor SSH abierto a Internet si se toman ciertas precauciones. Aunque habrá a quien lo que voy a exponer ahora le parecerá una temeridad, y habrá a quien le parecerá que estoy paranoico. En temas de seguridad suele haber opiniones para todos los gustos, así que yo expongo la mía ;)

Si vamos a tener el servidor SSH abierto a Internet es probable que lo necesitemos para un usuario concreto (seguramente para ti que eres quien está leyendo esto), mientras que los demás usuarios nunca tendrán necesidad de entrar desde el exterior. En el archivo de configuración de SSH podemos no sólo indicar qué usuarios se podrán conectar a nuestro servidor SSH, sino también desde qué ordenadores podrán hacerlo.

Así, podemos decirle que sólo permita entrar al usuario kalvy desde cualquier sitio (sea Internet o sea el ordenador viejo), y a los usuarios papa> y mama desde el ordenador viejo exclusivamente, mientras que cualquier otro usuario tenga prohibido el acceso.

Para ello, tendremos que editar el archivo /etc/ssh/sshd_config como root y añadir la línea:

AllowUsers kalvy papa@HAL9003 mama@HAL9003

donde HAL9003 es el nombre del ordenador viejo.

Además, yo suelo cambiar la línea

PermitRootLogin without-password

por

PermitRootLogin no

aunque es innecesario, ya que con el AllowUsers no se podría conectar ningún otro usuario no incluido en la lista, e incluso aunque root pudiese, no podría entrar ya que no tiene ninguna clave autorizada. Pero bueno, maniático que es uno :P

Tal y como está ahora, sólo el usuario kalvy podría entrar desde Internet por SSH. Y podría entrar tanto con una clave privada como con contraseña. Si quisiésemos que sólo se pudiese entrar mediante clave privada, deberíamos cambiar

#PasswordAuthentication yes

por

PasswordAuthentication no

Si vamos a permitir que se entre por contraseña, la contraseña DEBE ser fuerte. A partir de Mandriva 2010.0, diskdrake nos indica gráficamente mediante un candado lo fuerte que es una contraseña cuando la estamos estableciendo. Como regla general, que lleve no sólo letras sino también números intercalados y sea mayor de 10 caracteres.

Si vamos a entrar por clave privada, lo lógico sería usar una clave distinta a la que usamos para entrar desde el ordenador viejo. En lugar de llevarnos por ahí nuestra clave privada sin contraseña, lo normal sería dejarla bien guardadita en el ordenador y que nunca salga de allí, y de cara al exterior llevar una clave privada distinta que sí tenga contraseña. La clave pública correspondiente a nuestra clave privada con contraseña se añadiría al archivo /home/kalvy/.ssh/authorized_keys y listo. Así, si la clave privada cayese en manos equivocadas al menos tendríamos la tranquilidad de que no podrían entrar como Pedro por su casa, sino que necesitarían averiguar la contraseña de dicha clave.

Además de todo esto, ya fuera de la configuración del servidor de SSH, si vamos a tener el servidor SSH abierto a Internet con acceso por contraseña deberíamos instalar sshutout o algo similar. sshutout se encarga de ver quién intenta conectarse a nuestro servidor SSH y si se recibe cierta cantidad de intentos fallidos desde una misma dirección IP, bloquea dicha IP durante un tiempo. El objetivo es evitar ataques de fuerza bruta, como el usado para entrar en mi ordenador cuando tuve el desliz, que simplemente prueban muchos nombres y muchas contraseñas a ver si suena la flauta.

Ah, y sí, se me olvidaba, dentro de R2-D2 iba el actor Kenny Baker ;)

Problemas de la ejecución remota

Bueno, pues ya está, ya podemos entrar en el ordenador remoto mediante SSH sin contraseña y ejecutar aplicaciones, tanto de consola como gráficas.

Además, generalmente sólo necesitaremos ejecutar una aplicación remota concreta, y SSH tiene un sistema para eso. Simplemente tenemos que decirle el nombre de la aplicación, y SSH la ejecutará, sin abrir una consola y tener que ejecutarla allí. Para ello invocamos ssh de la siguiente manera:

ssh nombreDelOrdenador "nombreAplicación argumentos de la aplicación"

La orden ejecutada por SSH debe escaparse con comillas, de forma que las palabras separadas por espacios se consideran parte de una misma cadena, y no cadenas separadas.

Así que podemos hacer un enlace directo a la orden de ssh para ejecutarla con un doble click desde el escritorio por ejemplo (en KDE con un click con el botón derecho en el escritorio y Crear un nuevo -> Enlace a aplicación..., y en GNOME con un click con el botón derecho en el escritorio y Crear un lanzador...), como si estuviésemos ejecutando una aplicación en el ordenador local.

¡Qué bonito y fácil es todo! Desgraciadamente, ahora queda salir del mundo piruleta y volver al mundo real. No es oro todo lo que reluce.

Si ejecutamos una aplicación gráfica directamente indicándole el nombre a SSH se nos presentarán dos problemas.

El primero, que la aplicación estará en inglés. El motivo es que cuando ejecutamos una aplicación en el ordenador que tenemos delante, antes se habrá abierto una sesión, sea gráfica o de consola, pero habrá una sesión abierta. Cuando se abre una sesión, entre otras cosas, se establecen ciertas variables de entorno que las aplicaciones utilizan para saber cómo deben comportarse. Por ejemplo, se establecen las variables LANG, LANGUAGE y LC_MESSAGES, que indican a la aplicación en qué idioma deben mostrarse los textos.

Pero si ejecutamos la orden directamente por SSH no se abre una sesión de ningún tipo. SSH entra en el ordenador remoto y ejecuta la aplicación, a pelo. Ni sesión ni nada. Al no abrirse la sesión, no se establecen las variables para el lenguaje y la aplicación usa el idioma por defecto, que en el mundo del software libre es el inglés.

La solución a este problema es abrir una sesión antes de que se ejecute la orden. ¿Y cómo hacemos eso? Pues en lugar de ejecutar la orden tal cuál, la "envolvemos" con Bash, y le decimos a Bash que abra una sesión de consola. Así:

ssh nombreDelOrdenador "bash --login -c \"nombreAplicación argumentos de la aplicación\""

La orden ejecutada por Bash debe escaparse también con comillas como la ejecutada por SSH. Pero no podemos usar comillas normales, porque entonces la cadena que consideraría SSH sería bash --login -c . Por eso se utiliza \", que es una forma de que SSH considere la cadena entre comillas normales, y bash la orden entre comillas escapadas (\").

Haciendo eso nuestra aplicación gráfica ya se mostrará en el idioma adecuado. Pero sigue habiendo un segundo problema, que también ocurre incluso si abrimos una sesión remota por SSH (vamos, ssh nombreDelOrdenador, sin indicar la orden) y en dicha sesión ejecutamos la aplicación gráfica. Y el problema es que la sesión, al cerrar, no cierra sino que se queda tonta esperando.

Si la ejecutásemos en una consola, para terminar de cerrarla simplemente tendríamos que pulsar Ctrl+C. Pero si la ejecutamos a través de un enlace directo con doble click se quedará por ahí en ejecución hasta que lo matemos explícitamente con kill o similares, o hasta que cerremos la sesión de usuario. Además, si antes de cargarnos el proceso ssh intentásemos apagar el ordenador remoto, el gestor de acceso nos diría que hay una sesión remota abierta, si estamos seguros de que queremos apagar.

Sí, ciertamente confirmar que queremos cargarnos la sesión remota, o que tengamos procesos de SSH por ahí funcionando sin necesidad puede que no sea el fin del mundo. Pero sería mejor que SSH se cerrase limpiamente al terminar la aplicación, ¿verdad?

Pero la gran pregunta es ¿por qué no se cierra limpiamente? El motivo tenemos que buscarlo en la creciente complejidad de las aplicaciones de escritorio. Por sencilla que sea, una aplicación suele utilizar cierta infraestructura (aunque no lo necesite realmente). Y dicha infraestructura puede que necesite de ciertos demonios o servicios en ejecución para cumplir su función. Si dichos demonios no están activos, al ejecutar una aplicación los demonios se lanzan automáticamente. Peeero cuando la aplicación termina, los demonios siguen campando a sus anchas, no son eliminados. Como SSH espera a que todos los procesos que fueron creados bajo su tutela terminen antes de cerrarse, se queda esperando indefinidamente.

La solución en este caso pasa, cómo no, por cerrar los demonios después que termine la ejecución de la aplicación. Desafortunadamente, no es tan sencillo de solucionar como el caso anterior, y en ciertos casos ni siquiera es posible (al menos, no con mis conocimientos).

En el caso de las aplicaciones de KDE, podemos ejecutarlas de la siguiente manera:

ssh nombreDelOrdenador "bash --login -c \"kdeinit4 && kwrite && kdeinit4_shutdown\""

Esto ejecutará los demonios de KDE, cuando estén cargados ejecutará la aplicación (en este caso kwrite), y cuando termine la aplicación acabará con los demonios como si de una Buffy Cazavampiros cualquiera se tratase. La clave en este método está en "cuando termine la aplicación". Eso quiere decir que con algunas aplicaciones, como por ejemplo Amarok o Dolphin, no funcionará.

El motivo es que si ejecutamos en una consola Amarok veremos que el proceso que lanzamos termina enseguida, aunque Amarok esté ejecutándose. Amarok se "desdobla", y el proceso que lanzamos termina, mientras que su doble es el que sigue ejecutándose. En la orden para SSH mostrada, kdeinit4_shutdown se cargará los demonios cuando el proceso que ejecutamos nosotros mismos termine, lo que según acabamos de ver con Amarok no ocurre cuando termina Amarok, sino casi al instante de lanzarse. Al cargarse los demonios mientras Amarok está en plena ejecución, el resultado es probable que sea que Amarok casque.

Así que con Amarok, Dolphin o cualquier otra aplicación de KDE que al lanzar el proceso éste vuelva antes de que la aplicación se cierre, no tenemos más remedio que usar la orden sin kdeinit4 y kdeinit4_shutdown, quedándose SSH colgado hasta que lo cerremos explícitamente.

En el caso de GNOME, no puedo decir mucho, ya que no soy usuario y no tengo mucha idea de sus necesidades. No obstante, dando un vistazo rápido no encontré nada similar al kdeinit4 para lanzar y destruir los demonios necesarios. Ahora bien, tampoco sé qué necesidades tiene GNOME en cuanto a demonios se refiere. Imagino que sí que necesitará el demonio de DBUS, por lo que podemos hacer lo siguiente:

ssh nombreDelOrdenador "bash --login -c \"eval `dbus-launch --exit-with-session --sh-syntax aplicacionGnome`\""

dbus-launch lanza el demonio de DBUS y la opción exit-with-session sirve para que él mismo se "suicide" cuando termina la sesión de consola de Bash. Cuando dbus-launch se ejecuta es necesario lanzarlo mediante eval para que establezca ciertas variables de entorno que necesita. Las comillas invertidas, `, son la forma de ejecutar una orden y pasar su salida a eval.

Seguramente este método tendrá el mismo problema que el de KDE con aplicaciones que vuelvan antes de que la aplicación se cierre realmente. El caso de Nautilus es también especial porque, ignoro el motivo, no es que vuelva antes de que se cierre, sino que incluso después de cerrarlo no vuelve.

No obstante, no exploré mucho la ejecución remota de aplicaciones GNOME de esta manera, así que las contribuciones en este área son bienvenidas (y como en cualquier otra área del manual, realmente).

Quizás jugando con .bash_login y .bash_logout se pueda hacer que se lancen y se cierren los demonios necesarios, pero no exploré esa posibilidad.

Para terminar, dos comentarios sobre los enlaces directos/lanzadores de aplicaciones.

Lo primero, la notificación de lanzamiento no funciona, así que si está activada aparecerá hasta que se canse. O dicho de otra manera, la aplicación remota aparecerá y la notificación de lanzamiento aún seguirá activa un rato.

Y lo segundo, si queremos que el lanzador nos avise si intentamos ejecutar la aplicación remota cuando el ordenador remoto no está accesible, podemos añadir la opción -o ConnectTimeout 10 a la orden de SSH para que lo intente sólo durante 10 segundos, y que si SSH falla (porque se cumple el tiempo de espera) muestre un mensaje. En KDE todo esto podría hacerse con la orden:

ssh -o "ConnectTimeout 10" nombreDelOrdenador "bash --login -c \"kdeinit4 && kwrite && kdeinit4_shutdown\"" ||
kdialog --sorry "No se puede conectar con el otro ordenador"

(Realmente debería estar en una única línea, pero lo puse en dos para no hacer la página excesivamente ancha)