10.7.- Configurar SSH

Antiguamente, telnet era el sistema de acceso remoto preferido en modo texto de sistemas GNU/Linux y UNIX, pero presentaba serias carencias de seguridad, por lo que, durante los siguientes años, fue cediendo terreno a ssh, que es la herramienta preferida actualmente para el acceso remoto, pues, además, gestiona tareas de transferencia similares a las de ftp. Saber cómo configurar ssh es muy útil, sobre todo en lo que se refiere a sus fundamentos y su  fichero de configuración de en GNU/Linux. ssh es lo suficientemente complejo como para no poder abarcar más que los puntos básicos en este capítulo. Podemos obtener más detalles en la documentación de openssh o en algún libro sobre la materia.

Fundamentos de ssh

Linux permite el acceso remoto a través de varios servidores como telnet, VNC e incluso X. Lamentablemente la mayoría de estos métodos transfieren los datos sin cifrar, lo que implica que cualquiera puede monitorizar el tráfico de red y rastrear datos sensibles o, incluso, contraseñas. VNC y otros protocolos cifran las contraseñas, pero no el resto de los datos. Esta limitación supone un serio riesgo en la utilización de estas herramientas, al fin y al cabo, si utilizar un protocolo de acceso remoto implica entregar datos sensibles o comprometer todo el equipo, la utilidad del protocolo queda en entredicho.

Las herramientas de acceso remoto no cifrado son muy peligrosas cuando se trabaja como root, se accede directamente como root o a través de un usuario normal que emplea su, sudo u otra herramienta para obtener privilegios de root.

ssh fue diseñado para cerrar esta brecha de seguridad empleando técnicas de cifrado fuerte en todas las partes de la conexión de red, ssh cifra el intercambio de contraseñas y todas las  transferencias de datos subsiguientes, lo que lo convierte en un protocolo para acceso remoto mucho más seguro. Además del cifrado, proporciona funcionalidades para transferir ficheros y la posibilidad de hacer de túnel para otros protocolos de red y permitir, así, que protocolos de red no cifrados transporten sus datos aprovechando las ventajas de cifrado de ssh. Esta característica se suele emplear junto a X, posibilitando un acceso por GUI remoto y cifrado.

Las ventajas de ssh tienen algunas desventajas, la principal es que el cifrado y descifrado consumen tiempo de CPU, lo que ralentiza las conexiones y puede degradar el rendimiento global del sistema. No obstante, se trata de un efecto modesto, sobre todo en las conexiones en modo “texto plano”. Si lo utilizamos como túnel para un protocolo que transfiere muchos datos, puede que observemos una gran repercusión en el rendimientoIncluso en este caso, vale la pena esta reducción de velocidad si se tiene en cuenta la mejora de la seguridad.

Hay muchos servidores ssh disponibles, aunque el más popular es openssh (www.openssh.org). Fue una de las primeras implementaciones de código libre del protocolo ssh, desarrollado comercialmente por la SSH Comunications Security (http://www.ssh.com), cuyo servidor se vende ahora bajo el nombre de SSH Tectia. Estos y otros productos ssh pueden operar entre sí, asumiendo que todos ellos estén configurados para admitir, al menos, un nivel de protocolo ssh, pueden ser 1.3, 1.5 y 2.0, siendo 2.0 el preferido a causa de las vulnerabilidades que se conocen de las versiones anteriores.

openssh está estrechamente relacionado con el SO OpenBSD, por lo que su sitio web tiene cierta predilección por OpenBSD. Si visitamos el sitio, haremos click en el enlace Linux para encontrar el código fuente y binarios compatibles con Linux de openssh. Hoy en día, la mayoría de las distribuciones lo incluyen de serie.

openssh se puede iniciar a través de un súper servidor (inetd o xinetd) o un script de inicio SysV. Este último método es el preferido, ya que el servidor suele realizar tareas que utilizan mucho la CPU al iniciarse. Si lo iniciamos desde un súper servidor, openssh puede ralentizar las respuestas a las peticiones de conexión, sobre todo en sistemas con CPUs pobres. Las distribuciones actuales suelen incluir scripts de inicio SysV en sus paquetes ssh.

Si hacemos cambios en la configuración de ssh, puede que necesitemos pasarle las opciones reload o restart al script de inicio, como por ejemplo /etc/init.d/sshd reload. Independientemente de cómo se inicie, el nombre del servidor binario openssh es sshd que es el mismo que el nombre binario de SSH Tectia.

Definir las opciones de SSH de nuestro sistema

ssh funciona razonablemente bien nada mñas instalarlo, por lo que seguramente no necesitemos hacer cambios en su configuración. Si necesitamos hacer cambios, se gestionan en su mayor parte a través del fichero de configuración de ssh que está en /etc/ssh/sshd_config. También podemos editar algunos ficheros adicionales para limitar el acceso o cambiar el modo en que ssh gestiona el proceso de acceso.

Configurar las funcionalidades básicas de ssh

El fichero /etc/ssh/sshd_config se compone principalmente de líneas de opción que adoptan la siguiente forma:

opción  valor

tux_maestro_derNo debemos confundir el fichero sshd_config con el fichero ssh_config. El primero controla el servidor openssh mientras que el segundo controla el programa cliente de ssh.

Además de las líneas de configuración, el fichero contiene comentarios con almohadillas. La mayoría de ficheros de configuración de ejemplo incluyen un gran número de opciones que vienen comentadas y que especifican valores por defecto, por lo que, si las des comentamos sin cambiar los valores, el efecto será nulo. Para cambiar una opción eliminaremos la marca de comentario (#) y cambiaremos el valor. Los valores por defecto suelen ser apropiados para la mayoría de los sistemas. La siguiente lista muestra algunas opciones que recomendamos revisar y que podemos cambiar:

  • Protocol: en esta opción indicamos los niveles de protocolo de ssh. Los valores son 1 y 2. Podemos configurar openssh para que admita ambos protocolos separándolos por una coma. El nivel de protocolo 1 ha sido comprometido, por lo que la configuración más segura es definir protocol 2, aunque esto limita la capacidad del servidor para comunicarse con los clientes.
  • PermitRootLogin: esta opción se define como yes por defecto, lo que permite que openssh acepte accesos como root. Es más seguro que una configuración similar bajo telnet. Si queremos aumentar la seguridad, definiremos este valor como no, lo que hará que cualquiera que desee trabajar en remoto como root, tendrá que acceder primero como un usuario normal; esto significa que si un intruso ha conseguido la contraseña de root, también necesitará un usuario y su contraseña.
  • X11Forwarding: esta opción especifica si están activas las funcionalidades de túnel para X. Si definimos esta opción como yes, los usuarios remotos podrán ejecutar programas X a través de ssh, lo que degrada ligeramente la seguridad de X en el cliente, dependiendo de algunas otras opciones, de ahí que el valor por defecto sea no.

Podemos encontrar información sobre las opciones en la pagina MAN de sshd_config. Una vez realizados los cambios en la configuración de ssh no debemos olvidarnos de reiniciarlo utilizando el script de inicio SysV.

Claves de ssh

Parte de la seguridad de ssh depende de las claves de cifrado. Cada sistema servidor y cada usuario tiene un número (o clave) único a efectos de identificación. ssh utiliza un sistema de seguridad que emplea dos claves: una pública y otra privada, las dos están vinculas matemáticamente de manera que los datos cifrados con una clave pública concreta sólo se puedan descifrar con la clave privada coincidente. Cuando se establece una conexión, cada lado envía su clave pública al otro, después, cada lado cifra la información con la clave pública del otro lado. Esto asegura que tan sólo el destinatario deseado pueda descifrar los datos; es el primer paso del proceso aunque es fundamental. Los clientes ssh suelen conservar las claves públicas de los servidores con los que contactan, lo que permite detectar cambios en las claves públicas que puedan significar una señal de falsificación.

La mayoría de scripts de inicio SysV del servidor openssh suelen buscar las claves públicas y privadas almacenadas; si no las encuentran, las generan. En total, hacen falta de 4 a 6 claves: las claves pública y privada para las dos o tres herramientas de cifrado que admite ssh. Las claves se suelen almacenar en /etc/ssh y se llaman ssh_host_rsa_key y ssh_host_dsa_key en el caso de las privadas, añadiendo la extensión .pub al nombre del fichero en el caso de las públicas. Si nuestro sistema no dispone de estas claves y no podemos poner en funcionamiento el servidor ssh, podemos generarlas con el comando ssh-keygen:

ssh_keygen

Cada uno de estos comandos genera una clave privada (el parámetro -f  le da nombre) y una clave pública (con el mismo nombre pero añadiéndole .pub).

No debemos ejecutar estos comandos ssh-keygen si ya existen los ficheros clave ssh, ya que la sustitución de ficheros en uso hará que los clientes ya conectados al servidor, posiblemente, rechacen la conexión.

tux_maestro_derDebemos asegurarnos de que las claves privadas están adecuadamente protegidas, ya que si las obtiene un intruso, puede suplantar a nuestro sistema. Estos ficheros deberían tener permisos 0600 (-rw——-) y a root como propietario. Los ficheros de clave pública (con extensiones .pub) deberían poder ser leídos por todos los usuarios.

Cuando configuremos un sistema cliente es recomendable considerar la creación de una caché global de claves de host, ya que el programa ssh registra las claves de host para cada usuario individual (~/.ssh/known_hosts).  Cuando configuremos el cliente podemos rellenar el fichero ssh_known_hosts global, que se suele guardar en /etc o /etc/ssh. De esta manera nos aseguramos de que la lista de claves públicas sea tan precisa como las fuentes que empleemos para rellenar el fichero global. Eliminaremos los mensajes de confirmación cuando los usuarios se conecten a los hosts cuyas claves hemos seleccionado para incluir en el fichero global.

¿Cómo se crea este fichero?  Una manera sencilla es copiando el fichero desde una cuenta de usuario que se haya utilizado para conectarse a los servidores que queremos incluir. Por ejemplo, cp /home/ecernan/.ssh/known_hostst /etc/ssh/ssh_known_hosts debe ser revisado antes de copiarlo. Consta de una línea por cada host. Cada línea empieza por un nombre de host, una IP o ambos y continúa con el tipo de clave y la clave. Se puede ignorar la mayor parte de esta información, pero debemos prestar atención a los nombres de host y las direcciones IP. Debemos asegurarnos de que la lista incluya a todos los servidores ssh que queramos utilizar y de que excluya a servidores inapropiados o innecesarios. Para añadir entradas, utilizaremos la cuenta cuyo fichero estamos copiando y nos conectaremos al sistema que queremos añadir, ssh mostrará un aviso de que nos estamos conectando a un sistema desconocido, lo confirmaremos y recargaremos el fichero para comprobar la nueva entrada.

openssh 4.0 y posteriores realizan un hash de los nombres de host del fichero known_hosts. Cuando esta funcionalidad está activa se aplica un hash al nombre del host y se guarda en este formato, la idea es que pueda seguir autenticando los servidores ssh a los que se conectan, puesto que el hash del nombre del host coincide con el hash del nombre de host almacenado, pero si un intruso roba el fichero known_hosts, no podrá determinar las identidades de los ordenadores a los que nos hemos conectado.

Controlar el acceso por ssh

Podemos limitar el acceso a nuestro servidor ssh de varias maneras. El método más obvio y básico es a través de contraseñas. El método de autenticación más usual en ssh es emplear un nombre de usuario y una contraseña. El cliente ssh envía el nombre de usuario local automáticamente como parte de la línea de comandos, por lo que no se nos pedirá el nombre de usuario cuando accedamos a través de ssh. En caso de que el nombre del usuario en la máquina remota no sea el mismo que el usuario en la máquina local, deberemos especificar el usuario al hacer la conexión por ssh.

A parte de la autenticación de la contraseña. ssh incluye otros tipos de limitaciones:

  • TCP Wrappers: si ejecutamos ssh desde un súper servidor o si el servidor se compiló con soporte para TCPWrappers, podemos utilizar los ficheros /etc/hosts.allow y /etc/hosts.deny para limitar el acceso por dirección IP. Debemos tener en cuenta que si iniciamos ssh a través de un script de inicio SysV, sólo funcionará si el servidor se compiló con dicho soporte, que puede estar o no presente en el paquete ssh de nuestra distribución.
  • Cortafuegos: ssh utiliza el puerto tcp 22. Técnicamente, esta no es una característica de ssh, pero resulta verdaderamente útil para proteger el servidor.
  • /etc/nologin: cuando existe el fichero, ssh lo tiene en cuenta. La presencia de este fichero implica que sólo root puede acceder. El contenido del fichero se suele mostrar como un mensaje de error, sin embargo, ssh no hace esto.

Copiar ficheros a través de ssh

La mayoría de usuarios utilizan el cliente ssh, que proporciona un acceso remoto, por ejemplo, ssh otro sistema nos permite acceder a otro sistema utilizando el nombre de usuario que emplea el sistema cliente o podemos añadir un nombre de usuario, como en ssh usuario@otrosistema para acceder como usuario.

ssh incluye un comando para copiar ficheros: scp, que funciona de un modo similar al comando cp que copia comandos locales, debemos especificar el ordenador de destino y opcionalmente, el nombre de usuario justo antes del nombre del fichero de destino. Por ejemplo, para copiar el fichero masterpiece.c en la cuenta lisa de leonardo.example.com, escribiremos:

scp

Los dos puntos finales (:) son extremadamente importantes, ya que si se omiten scp funcionara como cp y acabaremos con un fichero llamado lisa@leonardo.example.com. Si queremos renombrar el fichero, podemos hacerlo incluyendo el nuevo nombre a continuación de los dos puntos (:).

Configurar accesos sin contraseña

Si utilizamos ssh o herramientas automatizadas frecuentemente, probablemente estemos cansados de escribir las contraseñas en cada conexión. Hay un medio para evitar este requisito: podemos configurar el cliente ssh con unas claves y darle la clave pública al ordenador servidor. Gracias a esto el cliente ssh podrá identificarse a sí mismo, obviando la necesidad de escribir una contraseña.

tux_maestro_derConfigurar ssh para trabajar sin contraseñas es cómodo, pero debilita la seguridad del sistema. Si alguien que no es de confianza consigue acceder a nuestra cuenta en el sistema cliente ssh, esta persona podrá acceder al servidor ssh. Por tanto, sólo deberíamos crear accesos sin contraseña desde clientes muy bien protegidos. Configurar el acceso de la cuenta root de esta manera es particularmente arriesgado.

Para configurar ssh de manera que no solicite una contraseña, seguiremos los siguientes pasos:

  1. Accederemos al cliente ssh como el usuario que accederá remotamente.
  2. Generaremos una clave ssh versión 2 de la siguiente manera:
    1. $ ssh-keygen -q -t rsa -f ~/.ssh/id_rsa -c ” -N “
  3. El paso 2 genera dos ficheros: id_rsa e id_rsa.pub. Transferiremos el segundo fichero al servidor ssh. Copiaremos el fichero con un nombre temporal, como temp.rsa.
  4. Seguidamente accederemos al servidor ssh, si lo hacemos mediante ssh, tendremos que escribir la clave.
  5. Añadiremos el contenido del fichero que acabamos de transferir al final del fichero ~/.ssh/authorized_keys (este fichero puede tener otros nombres, por lo que tendremos que comprobar que está presente). Para añadir el contenido escribiremos cat ~/temp.rsa >> ~/.ssh/authorized_keys, en caso de que guardemos el fichero original como ~/temp.rsa.

Si salimos del servidor e intentamos acceder de nuevo mediante ssh, no se nos solicitará contraseña, ya que los dos ordenadores gestionan automáticamente la autenticación. Si esto no funciona, es probable que el fichero ~/.ssh/autorized_keys necesite otro nombre. También es aconsejable comprobar que el fichero incluya una línea que coincida con el contenido del fichero original de clave pública del cliente. Algunos clientes pueden requerir la especificación de utilización de la versión 2 del protocolo ssh de la siguiente manera:

ssh_servidor

Utilizar ssh-agent

ssh-agent es otra opción para la autenticación ssh. Este programa solicita una contraseña para iniciar las conexiones,  por lo que resulta más seguro que configurar accesos sin contraseñas; sin embargo, ssh-agent recuerda las contraseñas, por lo que sólo necesitaremos escribirla una vez por cada sesión local. Para utilizar ssh-agent, seguiremos estos pasos:

  1. Seguiremos el procedimiento para activar los accesos sin contraseña que describimos anteriormente, pero con un cambio: omitiendo la opción -N del comando ssh-agent. En este paso se le solicitará una frase de contraseña, que será nuestra clave para todos los accesos ssh gestionados por ssh-agent.
  2. En el cliente ssh, escribiremos  ssh-agent /bin/bash. Esto iniciará ssh-agent que, a su vez, iniciará bash. Utilizaremos esta sesión de bash para los accesos ssh subsiguientes.
  3. En la nueva consola, escribiremos ssh-add ~/.ssh/id_rsa, lo que añadirá la clave rsa al conjunto gestionado por ssh-agent. En este momento, se nos pedirá que escribamos nuestra frase de contraseña.

A partir de este punto, cuando utilicemos ssh para conectarnos a un sistema remoto al que hayamos dado nuestra clave pública, no tendremos que escribir nuestra contraseña. No obstante, tendremos que repetir los pasos dos y tres cada vez que salgamos, ya que esto sólo se aplica a la consola iniciada en el paso 2 o a las consolas que iniciemos desde ésta.

Si utilizamos este recurso con frecuencia, podemos insertar ssh-agent en nuestro procedimiento de acceso normal. Por ejemplo, podemos editar /etc/passwd para utilizar ssh-agent /bin/bash como consola por defecto. En un acceso GUI podemos renombrar el script de acceso GUI normal (por ejemplo, cambiar  ~/.xsession por ~/.xsession-nossh) y crear un nuevo script de acceso GUI que llame a ssh-agent con el script renombrado como  el parámetro. Cada acción insertará ssh-agen en la raíz de nuestro árbol de procesos de usuario para que todas las llamadas a ssh utilicen ssh-agent.

Utilizar scripts de acceso ssh

La sesiones de acceso ssh en modo texto suelen ejecutar la consola configurada para el usuario, que ejecuta los scripts de acceso definidos para la consola. El servidor openssh también incluye su propio script de acceso, sshrc, que suele guardarse en /etc o /etc/bash. openssh ejecuta este script utilizando /bin/sh que, normalmente, es un enlace simbólico a bash, por lo que se puede tratar como un script de bash ordinario.

Configurar túneles para puertos ssh

ssh tiene la capacidad de extender sus capacidades de cifrado a otros protocolos, lo que requiere una configuración adicional, esto es lo que se denomina tunneling. Anteriormente describimos un tipo especial de túnel ssh vinculado a X.

La siguiente figura ilustra el concepto de túnel ssh. El ordenador servidor ejecuta dos programas de servidor: un servidor para el protocolo que utiliza el túnel (imap en este ejemplo) y un servidor ssh. El ordenador cliente ejecuta dos clientes: uno para el protocolo que utiliza el túnel y otro para ssh. El cliente ssh también escucha las conexiones del protocolo del túnel, por lo que hace tanto de cliente como de servidor. Cuando el cliente ssh recibe una conexión del cliente del protocolo del túnel, el resultado es que ésta se cifra utilizando ssh, se lleva por el túnel hasta el servidor ssh y se dirige al servidor de destino. En consecuencia, los datos pasan por la red en forma cifrada, aunque el protocolo objetivo no incluya cifrado.

sshtunel

Por defecto el servidor ssh permite crear túneles, pero, para asegurarnos, comprobaremos el fichero /etc/ssh/sshd_config y comprobaremos que la siguiente opción está des comentada:

allowtcp

Tendremos que cambiar no por yes; si ya está definida como yes, no deberemos cambiar nada en la configuración de ssh. En el lado del cliente estableceremos una conexión ssh especial, utilizando un cliente ssh normal con varios parámetros:

ssh_lado_servidor

Las opciones -N y -f le indican a ssh que no ejecute un comando remoto y que se ejecute en segundo plano tras solicitar una contraseña, son opciones necesarias para crear el túnel. -L especifica el puerto local en el que escuchar, el ordenador remoto al que conectarse y el puerto de dicho ordenador al que conectarse. En este ejemplo se escucha en el puerto local 142 y se conecta al puerto 143 de mail.luna.edu. El parámetro final (benf@mail.luna.edu) indica el nombre de usuario remoto y el ordenador hacia el que se dirige el túnel. Hay que tener en cuenta que este ordenador no tiene porque ser el mismo que el sistema especificado a través de -L.

tux_maestro_derSi queremos que ssh escuche en un puerto inferior a 1024 (puerto con privilegios) tendremos que ejecutar el programa como root. Si permitimos la escucha en un puerto no privilegiado podremos ejecutar ssh como usuario normal.

 Una vez establecido el túnel, utilizaremos el programa cliente (en este caso imap) para conectarnos al puerto local especificado por el parámetro -L (142 en este ejemplo). Por ejemplo, para redirigir el tráfico de imap debemos configurar un cliente de correo en el cliente para obtener el correo imap del puerto 142 para localhost. Cuando el cliente de correo haga esto, ssh entrará en acción y reenviará el trafico al servidor ssh, que pasará la información por el puerto 143 local y ejecutará el servidor imap real. Todo esto queda oculto para el programa lector de correo, para el el correo se obtiene de un servidor imap local.

Aspectos de la seguridad ssh

ssh está pensado para resolver problemas de seguridad en vez de crearlos, su uso supera al de telnet para los accesos remotos y puede asumir funciones de tipo ftp y hacer de túnel para otros protocolos. Por tanto, ssh es un extra para la seguridad. Sin embargo, como todos los servidores, puede suponer una responsabilidad en lo referente a seguridad al ejecutarlo de manera innecesaria o inadecuada. Lo ideal es configurar ssh para que sólo acepte conexiones del nivel 2 del protocolo y rechace accesos directos como root; también desactivaremos el redireccionamiento de X sino lo necesitamos. En la medida de lo posible, utilizaremos TCPWrappers o un cortafuegos para limitar las máquinas que pueden conectar con el servidor ssh. Debemos mantenerlo actualizado, ya que los bug pueden causar problemas.

Debemos considerar si necesitamos un servidor de acceso remoto en modo texto; resulta muy cómodo, lo suficiente como para justificar el modesto riesgo que implica. No obstante, en sistemas de muy alta seguridad, la seguridad puede mejorarse si utilizamos el ordenador exclusivamente desde la consola.

Un problema de seguridad de ssh poco habitual son sus claves, ya que los ficheros de clave privada son extremadamente sensibles y se deben proteger de los curiosos, además de las copias de seguridad de estos ficheros. No debemos dejar una cinta de copia del sistema en un sitio en el que se pueda robar con facilidad.

Utilizar GPG

ssh está diseñado para cifrar sesiones de acceso interactivo y transferencia de archivos. A veces necesitamos otro tipo de cifrado que proteja los mensajes de correo enviados a otra persona utilizando otros medios. Los correos no son una herramienta segura para transferir información, ya que la mayoría de los mensajes pasan a través de varios servidores de correo y routers. Si cualquiera de estos puntos está comprometido, se podría rastrear el tráfico del correo y extraer información sensible. Cifrando el correo mantendremos la privacidad de estos detalles.

La herramienta habitual para cifrar correos es gnu privacy guard (gpg, http://www.gnupg.org). Este paquete es una reimplementación bajo código libre de la herramienta propietaria gpg. Además de cifrar mensajes completos, gpg permite firmar digitalmente los mensajes. De esta manera los destinatarios que carecen del software gpg o las claves apropiadas podrán leer los mensajes, pero no verificar que su contenido no ha sido alterado.

Generar e importar claves

Lo primero que debemos hacer es instalar el software; probablemente, la distribución ya lo incluya como un paquete estándar, por lo que podremos instalarlo con nuestro gestor de paquetes. Después, debemos generar las claves, que son similares en concepto a las claves ssh: necesitaremos una clave privada (clave secreta) y una pública. La clave privada se mantiene en privado y la pública está disponible públicamente.

La clave privada se utiliza para firmar los mensajes y la pública la utilizan los lectores para realizar las verificaciones. Otra opción es cifrar un mensaje con la clave pública de otro usuario, con lo que sólo se podrá descifrar con la clave privada de dicho usuario.

Para poder generar las claves, se utiliza el programa gpg y su opción –gen-key:

gpg

El programa hará una serie de preguntas, la mayoría de ellas se pueden responder con los valores por defecto, tendremos que escribir nuestro nombre completo y la dirección de correo. Las claves se guardan en ~/.gnupguna vez generadas, podremos exportar la clave pública:

gpg_2

Este comando guarda la clave pública asociada con nombre en el fichero gpg.pub; podemos usar nuestra dirección de correo como nombre y, si creamos claves públicas adicionales o añadimos claves públicas de otros, podemos especificar su nombre al exportarlas. También podemos hacer que nuestra clave esté disponible para otras personas para que puedan cifrar los mensajes de correo que nos mandan o verificar los que nosotros firmamos. Si añadimos la opción –armor se genera una salida ASCII, que es preferible si tenemos pensado mandar por correo la clave pública. Podemos colgar el fichero en nuestro sitio web, transferirlo como un adjunto de un correo o distribuirlo de varias maneras.

Para cifrar el correo que enviemos debemos obtener las claves públicas de los destinatarios. Cuando lo hayamos hecho podremos añadir nuestras claves al deposito de claves o keyring, que es el conjunto de claves que mantiene gpg:

gpg_3

Este comando añade filename a nuestro conjunto de claves públicas que pertenecen a otras personas.

tux_maestro_derAunque las claves públicas son por definición públicas, al utilizarlas hay que tener en cuenta algunos detalles relacionados con la seguridad. En concreto, debemos asegurarnos de que utilizamos una clave pública legítima. En teoría, alguien mal intencionado podría publicar una clave pública falsa para obtener información sensible o falsificar un correo. Por tanto, debemos utilizar el método de comunicación más seguro para distribuir nuestra clave pública y para recibir claves públicas de otros.

Cuando hayamos creado nuestra propia clave e importado claves de otros, podremos ver qué claves hay disponibles de la siguiente manera:

 
key_list_keys

Las líneas uid contienen identificadores que se utilizan cuando se cifran o descifran los datos, por lo que debemos prestar una especial atención a esta información.

Cifrar y descifrar datos

Para cifrar datos utilizaremos gpg con –out–encrypt y opcionalmente –recipient–armor:

gpg_out

Podemos utilizar la uid de una salida gpg –list-keys, sólo la parte de la dirección del correo como uid en este comando. El resultado será un nuevo archivo fichero-cifrado, que contiene una versión cifrada del archivo fichero-original. Si omitimos la opción –armor, el archivo resultante será un fichero binario; si queremos enviarlo en un correo, tendremos que hacerlo como adjunto o codificarlo de algún otro modo para enviarlo por el sistema de correo de tipo texto. –armor produce una salida en ASCII, con lo que podremos cortar y pegar el mensaje cifrado en un correo o enviarlo como adjunto.

Si recibimos un mensaje o fichero cifrado con nuestra clave pública podemos revertir el cifrado utilizando la opción –decrypt:

gpg_out2

Se nos pedirá que introduzcamos nuestra frase de contraseña y obtendremos una versión descifrada del fichero original.

En la práctica, gpg puede ser incluso más fácil de utilizar de lo que se puede pensar a raíz de esta descripción. Se utiliza principalmente para proteger y verificar correos electrónicos, por lo que la mayoría de clientes de correo de GNU/Linux, proporcionan interfaces gpg. Esta opciones llaman a gpg con las opciones apropiadas para cifrar, firmar o descifrar mensajes. Los detalles varían de un cliente de correo a otro.

Firmar mensajes y verificar firmas

gpg se utiliza para firmar mensajes de modo que los destinatarios sepan de quien proceden. Para ello se utilizan las opciones –sing–clearsing:

gpg_clearsing

La opción –sing crea un nuevo fichero con el mismo nombre que el original, pero añadiendo la extensión -gpg. Este fichero se cifra utilizando nuestra clave privada, por lo que sólo se podrá descifrar con nuestra clave pública, lo que significa que cualquiera que conozca nuestra clave pública podrá leer el mensaje y todos sabrán que de dónde procede. La opción –clearsing funciona de manera similar, pero deja el mensaje de texto sin cifrar y sólo añade una firma cifrada que se puede verificar utilizando nuestra clave pública. –clearsing crea un fichero con un nombre que acaba en .asc. Si recibimos un mensaje firmado, podemos verificar la firma utilizando la opción –verify:

gpg_verify

Si cualquiera de la claves de nuestro depósito de claves puede decodificar o verificar la firma, gpg mostrará un mensaje Good Signature (firma correcta). Para leer un mensaje cifrado mediante la opción –sing, debemos descifrarlo mediante la opción –decrypt que vimos anteriormente.

Espero que haya sido de su interés ytux-161406_640 que haya servido para saber un poco más sobre las interioridades de Linux.

Anuncios