Documentation for a newer release is available. View Latest

OpenSSH

indexterm:[OpenSSH] `SSH` (Secure Shell) es un protocolo que facilita comunicaciones seguras entre dos sistemas usando una arquitectura cliente-servidor y permitiendo a los usuarios acceder a los servidores remotamente. De modo distinto a otros protocolos de comunicación como `FTP`, `Telnet`, o [command]#rlogin#, SSH cifra el inicio de sesión lo que dificulta la conexión a los intrusos para recolectar contraseñas no cifradas.

El programa ssh está diseñado para reemplazar a aplicaciones más antiguas y menos seguras usadas para acceder a hosts remotos como telnet o rsh. Un programa relacionado llamado scp reemplaza a los programas mas antiguos diseñados para copiar ficheros entre hosts como rcp. Como estas aplicaciones mas antiguas no cifran las contraseñas transmitidas entre el cliente y el servidor evítelos siempre que sea posible. Usando métodos seguros para acceder a sistemas remotos disminuye el riesgo tanto para el sistema cliente como para el host remoto.

Fedora incluye el paquete general OpenSSH, openssh, así como los paquetes servidor OpenSSH, openssh-server y cliente openssh-clients. Tenga en cuenta que los paquetes OpenSSH requieren el paquete OpenSSL openssl-libs, que instala diversas importantes librerías de criptográficas que habilitan a OpenSSH para suministrar comunicaciones cifradas.

El Protocolo SSH

¿Por qué Usar SSH?

Los potenciales intrusos tienen diversas herramientas a su disposición que les habilitan para interrumpir, interceptar y reenrutar el tráfico de red en su esfuerzo para obtener acceso a un sistema. En términos generales estas amenazas se pueden clasificar como sigue:

Interceptación de la comunicación entre dos sistemas: El atacante puede estar en cualquier parte de la red entre las partes que se comunican, copiando cualquier información que se pasen entre ellos. Puede interceptar y mantener la información o alterar la información y enviarla al receptor de destino.

Este ataque se lleva a cabo normalmente usando un analizador de paquetes, una utilidad de red bastante común que captura cada paquete que fluye por la red y analiza su contenido.
Suplantación de un host en particular: El sistema atacante está configurado para hacerse pasar por el destinatario previsto de una transmisión. Si funciona esta estrategia, el sistema del usuario permanece sin darse cuenta de que esta comunicando con el host equivocado.

Este ataque puede ser llevado a cabo usando una técnica conocida como envenenamiento DNS, o por medio de la llamada suplantación de IP. En el primer caso, el intruso utiliza un servidor DNS descifrado para señalar a los sistemas clientes un host duplicado maliciosamente. En el segundo caso, el intruso envía paquetes de red falsificados que parecen que provienen del host de confianza.

Ambas técnicas interceptan información potencialmente sensible y, si la interceptación se hace por razones hostiles, los resultados pueden ser desastrosos. Si se usa SSH para acceso remoto al shell y la copia de archivos estas amenazas de seguridad pueden ser disminuidas considerablemente. Esto es porque el cliente y el servidor SSH usan firmas digitales para verificar su identidad. Además, toda la comunicación entre el cliente y el servidor está encriptada. Los intentos de suplantar la identidad de cada lado de la comunicación no funcionan puesto que cada paquete es encriptado usando una clave solo conocida por los sistemas local y remoto.

Características Principales

El protocolo SSH suministra las siguientes salvaguardias:

Nadie puede hacerse pasar por el servidor previsto: Después de una conexión inicial, el cliente puede verificar que está conectado al mismo servidor al que se ha conectado previamente.
Nadie puede capturar la información de autenticación: El cliente transmite su información de autenticación al servidor usando un cifrado fuerte de 128 bit.
Nadie puede interceptar la comunicación: Todos los datos enviado y recibidos durante una sesión son transferidos usado un cifrado de 128 bit, haciendo que las transmisiones interceptadas sean extremadamente difíciles de desencriptar y leer.

Adicionalmente, también ofrece las siguientes opciones:

Provee de medios seguros para usar aplicaciones gráficas sobre una red: Usando una técnica llamada X11 forwarding, el cliente puede reenviar aplicaciones X11 (X Window System) desde el servidor. Tenga en cuenta que si establece la opción ForwardX11Trusted a yes o utiliza SSH con la opción -Y, usted puentea los controles de la extensión X11 SECURITY, lo que puede llevar a un compromiso de la seguridad.
Proporciona una forma de proteger protocolos que de otro modo serían inseguros: El protocolo SSH encripta todo lo que envía y recibe. Usando una técnica llamada reenvío de puertos, un servidor SSH puede llegar a convertirse en un conducto para proteger protocolos que de otro modo serían inseguros, como POP, y aumenta la seguridad general del sistema y de los datos.
Puede ser usado para crear un canal seguro: El servidor OpenSSH y el cliente pueden ser configurados para crear un túnel similar a una red privada virtual VPN para el tráfico entre las máquinas servidor y cliente.
Soporta autenticación Kerberos: Los servidores y los clientes OpenSSH pueden ser usados para autenticarse usando la implementación GSSAPI (Generic Security Services Application Program Interface) del protocolo de autenticación de red Kerberos.

Versiones del Protocolo

Actualmente existen dos versiones de SSH: versión 1 y versión 2. El conjunto OpenSSH bajo Fedora usa SSH versión 2, que tiene un algoritmo de intercambio de claves mejorado que no es vulnerable a la debilidad conocida de la versión 1. Sin embargo, por razones de compatibilidad, el conjunto OpenSSH soporta también conexiones de versión 1, aunque de forma predeterminada la versión 1 está deshabilitada y es necesario que sea habilitada en los archivos de configuración.

Evitar el uso de SSH versión 1

Para asegurar la máxima seguridad para su conexión, se recomienda que solo se use para servidores y clientes SSH compatible con versión 2 siempre que sea posible.

Secuencia de Eventos de una Conexión SSH

La siguiente serie de eventos ayudan a proteger la integridad de la comunicación SSH entre dos hosts.

Se hace un apretón de manos criptográfico de modo que el cliente puede verificar que está comunicando con el servidor correcto.
La capa de transporte de la conexión entre el cliente y el host remoto se encripta usando un cifrado simétrico.
El cliente se autentica ante el servidor.
El cliente interactúa con el host remoto sobre una conexión cifrada.

Capa de Transporte

El papel principal de la capa de transporte es facilitar una comunicación segura y protegida entre los dos host en el momento de la autenticación y durante la comunicación subsiguiente. La capa de transporte cumple esto manejando el cifrado y descifrado de los datos y proporcionado protección de la integridad de los paquetes de datos cuando son enviados y recibidos. La capa de transporte también proporciona compresión acelerando la transferencia de información.

Una vez que un cliente SSH contacta con un servidor la información de claves es intercambiada de modo que los dos sistemas pueden construir correctamente la capa de transporte. Durante este intercambio ocurren las siguiente cosas:

Se intercambian las claves
Se determina el algoritmo de encriptación de clave pública
Se determina el algoritmo de cifrado simétrico
Se determina el algoritmo de autenticación de mensajes
Se determina el algoritmo de hash

Durante el intercambio de claves el servidor se identifica ante el cliente con una única clave de host. Si el cliente nunca ha comunicado con el servidor concreto antes, la clave de host del servidor es desconocida por el cliente y no se conecta. OpenSSH notifica al usuario que la autenticidad del host no puede ser establecida y le indica al usuario que la acepte o la rechace. Se espera que el usuario verifique de forma independiente la clave del nuevo host antes de aceptarla. En las siguiente conexiones la clave del host servidor se comprueba contra la versión guardada en el cliente, proporcionando la confianza de que el cliente está comunicando con el servidor que se pretende. Si, en el futuro, la clave del host no coincide, el usuario debe quitar la versión guardada del cliente antes de que suceda la conexión.

Verifica siempre la integridad de un nuevo servidor SSH

Es posible que un atacante se haga pasar por un servidor SSH durante el contacto inicial puesto que el sistema local no conoce la diferencia entre el servidor al que se pretende llegar y uno falso establecido por un atacante. Para ayudar a evitar esto, verifique la integridad del nuevo servidor SSH contactando con el administrador del servidor antes de conectar por primera vez o en el caso de que la clave del host no coincida.

SSH está diseñado para trabajar con casi cualquier clase de algoritmo de clave o formato de codificación. Después de un intercambio inicial de claves crea un valor hash usado para el intercambio y un valor de secreto compartido, los dos sistemas empiezan inmediatamente a calcular las nuevas claves y algoritmos para proteger la autenticación y los futuros datos que se envíen por la conexión.

Después de que se han transmitido una cierta cantidad de datos usando una clave y un algoritmo dado (la cantidad exacta depende de la implementación SSH), se procede a otro intercambio, generado otro conjunto de valores hash y un nuevo valor de secreto compartido. Aunque un atacante sea capaz de determinar el hash y el secreto compartido esta información solo es útil durante un limitado período de tiempo.

Autenticación

Una vez que la capa de transporte ha construido un túnel seguro para pasar la información entre los dos sistemas, el servidor le dice al cliente los diferentes métodos de autenticación soportados, bien usando una clave privada codificada o tecleando una contraseña. En ese momento el cliente intenta autenticarse ante el servidor usando una de estos métodos soportados.

Los servidores SSH y los clientes pueden ser configurados para permitir diferentes tipos de autenticación, lo que da a cada parte una cantidad óptima de control. El servidor puede decidir que métodos de cifrado soporta en base a su modelo de seguridad y el cliente puede elegir el orden de los métodos de autenticación entre las opciones disponibles.

Canales

Después de una autenticación exitosa sobre la capa de transporte SSH, se abren múltiples canales por medio de una técnica llamada multiplexado^[1]. Cada uno de estos canales manejas la comunicación de diferentes sesiones de terminal y el reenvío de sesiones X11.

Tanto los clientes como los servidores pueden crear un nuevo canal. A cada canal se le asigna un número diferente en cada extremo de la conexión. Cuando el cliente intenta abrir un nuevo canal, el cliente envía el número del canal junto con la petición. Esta información es almacenada por el servidor y utilizada para comunicar directamente por ese canal. Esto se hace para que los diferentes tipos de sesión no afecten unas a otras y de este modo cuando una sesión dada termina su canal puede ser cerrado sin interrumpir la conexión SSH principal.

Los canales también soportan control de flujo, lo que les permite enviar y recibir datos de una manera ordenada. De este modo, los datos no se envían por el canal hasta que el cliente recibe un mensaje de que el canal está abierto.

El cliente y el servidor negocian las características de cada canal automáticamente, dependiendo del tipo de servicio que pida el cliente y la manera en que el usuario está conectado a la red. Esto permite una gran flexibilidad en el manejo de diferentes tipos de conexiones remotas sin tener que cambiar la infraestructura básica del protocolo.

Configurando OpenSSH

Con el objetivo de llevar a cabo las tareas descritas en este sección, usted debe tener privilegios de superusuario. Para obtenerlos, acceda como root tecleando:

su -

Archivos de Configuración

Hay dos conjuntos diferentes de archivos de configuración: unos para los programas cliente (esto es, ssh, scp y sftp) y otros para el servidor (el demonio sshd). La información de configuración SSH para todo el sistema se almacena en el directorio /etc/ssh/ como se describe en Archivos de configuración de todo el sistema. La información de configuración SSH específica del usuario se almacena en ~/.ssh/ dentro del directorio home del usuario como se describe en Archivos de configuración específicos del usuario.

Table 1. Archivos de configuración de todo el sistema
Archivo	Descripción
`/etc/ssh/moduli`	Contiene los grupos Diffie-Hellman usados por el intercambio de claves Diffie-Hellman que es crítica para la construcción de una capa de transporte segura. Cuando se intercambian las claves al comienzo de una sesión SSH, se crea un valor secreto, compartido, que no puede ser determinado por ninguna de las partes solas. Este valor es después usado para la autenticación del equipo.
`/etc/ssh/ssh_config`	El archivo de configuración predeterminado del cliente SSH. Tenga en cuenta que este es anulado por `~/.ssh/config` si existe.
`/etc/ssh/sshd_config`	El archivo de configuración del demonio sshd.
`/etc/ssh/ssh_host_ecdsa_key`	La clave privada ECDSA usada por el demonio sshd.
`/etc/ssh/ssh_host_ecdsa_key.pub`	La clave pública ECDSA usada por el demonio sshd.
`/etc/ssh/ssh_host_key`	La clave privada RSA usada por el demonio sshd para la versión 1 del protocolo SSH.
`/etc/ssh/ssh_host_key.pub`	La clave pública RSA usada por el demonio sshd para la versión 1 del protocolo SSH.
`/etc/ssh/ssh_host_rsa_key`	La clave privada RSA usada por el demonio sshd para la versión 2 del protocolo SSH.
`/etc/ssh/ssh_host_rsa_key.pub`	La clave pública RSA usada por el demonio sshd para la versión 2 del protocolo SSH.
`/etc/pam.d/sshd`	El archivo de configuración PAM configuration para el demonio sshd.
`/etc/sysconfig/sshd`	Archivo de configuración para el servicio `sshd`.

Table 2. Archivos de configuración específicos del usuario
Archivo	Descripción
`~/.ssh/authorized_keys`	Contiene una lista de las claves públicas autorizadas para los servidores. Cuando el cliente conecta con un servidor, el servidor autentica al cliente comprobando su clave pública firmada almacenada dentro de este archivo.
`~/.ssh/id_ecdsa`	Contiene la clave privada ECDSA del usuario.
`~/.ssh/id_ecdsa.pub`	La clave pública ECDSA del usuario.
`~/.ssh/id_rsa`	La clave privada RSA usada por ssh.
`~/.ssh/id_rsa.pub`	La clave pública RSA usada por ssh.
`~/.ssh/id_ed25519`	La clave privada EdDSA usada por ssh.
`~/.ssh/id_ed25519.pub`	La clave pública EdDSA usada por ssh.
`~/.ssh/known_hosts`	Contiene las claves de host de los servidores SSH a los que ha accedido el usuario. Este archivo es muy importante para asegurar que el cliente SSH está conectando con el servidor SSH correcto.

Para información sobre las diversas directivas que se pueden usar en los archivos de configuración SSH vea las páginas de manual ssh_config(5) y sshd_config(5).

Iniciando un Servidor OpenSSH

Asegúrese de tener instalados los paquetes relevantes

Para correr un servidor OpenSSH debe tener instalado el paquete openssh-server. Vea Instalando Paquete para más información sobre como instalar nuevos paquetes en Fedora Rawhide.

Para iniciar el demonio sshd en la sesión en marcha teclee, como root, lo siguiente en el símbolo del sistema:

~]# systemctl start sshd.service

Para parar el demonio sshd corriendo en la sesión en curso utilice, como root, el siguiente comando:

~]# systemctl stop sshd.service

Si desea que el demonio se inicie automáticamente en el momento del arranque teclee como root:

~]# systemctl enable sshd.service
ln -s '/usr/lib/systemd/system/sshd.service' '/etc/systemd/system/multi-user.target.wants/sshd.service'

Vea en Servicios y Demonios más información sobre como configurar servicios en Fedora.

Tenga en cuenta que si reinstala el sistema se creará un nuevo conjunto de claves de identificación. Como consecuencia los clientes qu se hubieran conectado al sistema con cualquiera de las herramientas OpenSSH antes de la instalación verán el siguiente mensaje:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.

Para evitar esto, usted puede hacer copia de seguridad de los archivos relevantes del directorio /etc/ssh/ (vea en Archivos de configuración de todo el sistema una lista completa) y recupérelos siempre que reinstale el sistema.

Requerimientos de SSH para Conexiones Remotas

Para que SSH sea verdaderamente efectivo la utilización de protocolos de conexión inseguros debería estar prohibida. De lo contrario una contraseña de usuario se puede proteger usando SSH para una sesión, solo para ser capturada más tarde al iniciar una sesión usando Telnet. Algunos servicios a deshabilitar son telnet, rsh, rlogin y vsftpd.

Estos servicios no están instalados de modo predeterminado en Fedora. Si es necesario, para asegurarse de que estos servicios no están corriendo, teclee los siguientes comandos en el símbolo del sistema:

systemctl stop telnet.service
systemctl stop rsh.service
systemctl stop rlogin.service
systemctl stop vsftpd.service

Para deshabilitar que corran estos servicios en el arranque teclee:

systemctl disable telnet.service
systemctl disable rsh.service
systemctl disable rlogin.service
systemctl disable vsftpd.service

Vea en Servicios y Demonios más información sobre como configurar servicios en Fedora.

Utilizando Autenticación Basada en Clave

To improve the system security even further, generate SSH key pairs and then enforce key-based authentication by disabling password authentication. To do so, open the /etc/ssh/sshd_config configuration file in a text editor such as vi or nano, and change the PasswordAuthentication option as follows:

PasswordAuthentication no

If you are working on a system other than a new default installation, check that PubkeyAuthentication no has not been set. If connected remotely, not using console or out-of-band access, testing the key-based log in process before disabling password authentication is advised.

Para ser capaz de utilizar ssh, scp o sftp para conectarse al servidor desde una máquina cliente, genere un par de claves de autorización siguiendo los pasos de abajo. Tenga en cuenta que las claves se deben generar por cada usuario por separado.

Fedora Rawhide uses SSH Protocol 2 and RSA keys by default (see Protocol Versions for more information).

No genere los pares de claves como root

Si completa los pasos como root, solo root será capaz de usar las claves.

Haga copia de seguridad de su directorio ~/.ssh/

Si desea reinstalar su sistema y mantener los pares de claves generadas previamente, haga copia de seguridad de su directorio ~/.ssh/. Después de reinstalar recupere la copia en su directorio home. Este proceso puede ser hecho por todos los usuarios de su sistema incluido root.

Generando los Pares de Claves

Para generar un par de claves RSA para la versión 2 del protocolo SSH, siga estos pasos:

Generar un par de claves RSA tecleando lo siguiente en el símbolo del sistema:

~]$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/USER/.ssh/id_rsa):

Pulse Enter para confirmar la localización predeterminada, ~/.ssh/id_rsa, para la clave recientemente creada.

Introduzca una frase de paso y confírmela introduciéndola otra vez cuando se le pida. Por razones de seguridad evite usar la misma contraseña que utiliza para acceder a su cuenta.

Después de esto se le presentará un mensaje similar a este:

Your identification has been saved in /home/USER/.ssh/id_rsa.
Your public key has been saved in /home/USER/.ssh/id_rsa.pub.
The key fingerprint is:
e7:97:c7:e2:0e:f9:0e:fc:c4:d7:cb:e5:31:11:92:14 USER@penguin.example.com
The key's randomart image is:
+--[ RSA 2048]----+
|             E.  |
|            . .  |
|             o . |
|              . .|
|        S .    . |
|         + o o ..|
|          * * +oo|
|           O +..=|
|           o*  o.|
+-----------------+

De modo predeterminado los permisos del directorio ~/.ssh/ están establecidos a rwx------ o 700 expresado en anotación octal. Esto es para asegurar que solo el USER puede ver los contenidos. Si se requiere esto se puede confirmar con el siguiente comando:
```
~]$ ls -ld ~/.ssh
drwx------. 2 USER USER 54 Nov 25 16:56 /home/USER/.ssh/
```
Para copiar la clave pública a una máquina remota, envíe un comando con el siguiente formato:
```
 ssh-copy-id user@hostname
```
Esto copiará la clave pública ~/.ssh/id*.pub modificada más recientemente si todavía no está instalada. Alternativamente, especifique el nombre de archivo de la clave pública como sigue:
```
ssh-copy-id -i ~/.ssh/id_rsa.pub user@hostname
```
Esto copiará el contenido de ~/.ssh/id_ecdsa.pub en ~/.ssh/authorized_keys de la máquina a la que se desea conectar. Si el fichero ya existe, las claves se añadirán a su final.

Para generar un par de claves ECDSA para la versión 2 del protocolo SSH siga estos pasos:

Generar un par de claves ECDSA tecleando lo siguiente en el símbolo del sistema:

~]$ ssh-keygen -t ecdsa
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/USER/.ssh/id_ecdsa):

Pulse Enter para confirmar la localización predeterminada, ~/.ssh/id_ecdsa, para la clave recientemente creada.

Introduzca una frase de paso y confírmela introduciéndola otra vez cuando se le pida. Por razones de seguridad evite usar la misma contraseña que utiliza para acceder a su cuenta.

Después de esto se le presentará un mensaje similar a este:

Your identification has been saved in /home/USER/.ssh/id_ecdsa.
Your public key has been saved in /home/USER/.ssh/id_ecdsa.pub.
The key fingerprint is:
fd:1d:ca:10:52:96:21:43:7e:bd:4c:fc:5b:35:6b:63 USER@penguin.example.com
The key's randomart image is:
+--[ECDSA  256]---+
|       .+ +o     |
|       . =.o     |
|        o o +  ..|
|         + + o  +|
|        S o o oE.|
|           + oo+.|
|            + o  |
|                 |
|                 |
+-----------------+

De modo predeterminado los permisos del directorio ~/.ssh/ están establecidos a rwx------ o 700 expresado en anotación octal. Esto es para asegurar que solo el USER puede ver los contenidos. Si se requiere esto se puede confirmar con el siguiente comando:
```
~]$ ls -ld ~/.ssh
              ~]$ ls -ld ~/.ssh/
drwx------. 2 USER USER 54 Nov 25 16:56 /home/USER/.ssh/
```
Para copiar la clave pública a una máquina remota, envíe un comando con el siguiente formato:
```
ssh-copy-id USER@hostname
```
Esto copiará la clave pública ~/.ssh/id*.pub modificada más recientemente si todavía no está instalada. Alternativamente, especifique el nombre de archivo de la clave pública como sigue:
```
ssh-copy-id -i ~/.ssh/id_ecdsa.pub USER@hostname
```
Esto copiará el contenido de ~/.ssh/id_ecdsa.pub en ~/.ssh/authorized_keys de la máquina con la que desea conectar. Si el fichero existe ya se añadirá al final del mismo.

See Configuring ssh-agent for information on how to set up your system to remember the passphrase.

No comparta nunca su clave privada

La clave privada es solo para su uso personal y es importante que nunca se la dé a nadie.

Configurando ssh-agent

Para almacenar su frase de paso de modo que no tenga que introducirla cada vez que inicie una conexión con una máquina remota, puede usar el agente de autenticación ssh-agent.

Para guardar su frase de paso para un símbolo de sistema concreto, use el siguiente comando:

~]$ ssh-add
Enter passphrase for /home/USER/.ssh/id_rsa:

Tenga en cuenta que cuando salga del sistema su frase de paso será olvidada. Debe ejecutar el comando cada vez que acceda a una consola virtual o a una ventana de terminal.

Usando Certificado de Autenticación OpenSSH

Introducción a los Certificados SSH

La utilización de la criptografía de clave pública para la autenticación requiere la copia de la clave pública de cada cliente en cada servidor al que ese cliente pretenda acceder. Este sistema no escala bien y puede ser una carga administrativa. La utilización de una clave pública de una autoridad de certificación (CA) para autenticar los certificados de los clientes evita la necesidad de copiar las claves entre múltiples sistemas. Para que el sistema de Infraestructura de Certificado de Clave Pública X.509 proporcione una solución a esta cuestión, hay un proceso de envío y validación, con tarifas asociadas, con el objetivo de obtener un certificado firmado. Como alternativa, OpenSSH soporta la creación de certificados sencillos y una infraestructura de CA asociada.

Los certificados OpenSSH contienen una clave pública, información de la identidad y restricciones de validación. Son firmados con una clave pública SSH estándar usando la utilidad ssh-keygen. El formato del certificado se describe en /usr/share/doc/openssh-version/PROTOCOL.certkeys.

La utilidad ssh-keygen soporta dos tipos de certificados: usuario y host. Los certificados de usuario autentican a las usuarios en los servidores, mientras que los certificados de host autentican los hosts servidores en los usuarios. Para que lo certificados se utilicen para la autenticación de usuarios o host, sshd debe configurarse para confiar en la clave pública de la CA.

Soporte para Certificados SSH

El soporte para la autenticación de certificado de usuarios y hosts usando el nuevo formato de certificado OpenSSH fue introducido en Fedora 13, en el paquete openssh-5.4p1-1.fc13. Si se requiere, para asegurar que el último paquete OpenSSH está instalado, introduzca como root el siguiente comando:

~]# dnf install openssh
Last metadata expiration check performed 0:58:01 ago on Sun Sep  6 16:07:22 2015.
Package openssh-7.1p1-1.fc23.x86_64 is already installed, skipping.

Creación de Firmas de Certificados SSH CA

Se requieren los dos tipos de certificados, certificados de host y certificados de usuario. Se considera mejor tener dos claves separadas para firmar los dos certificados, por ejemplo ca_user_key y ca_host_key, sin embargo es posible usar solo una clave CA para firmar ambos certificados. Es también más fácil seguir los procedimientos se usan claves separadas, de manera que los ejemplos que siguen usarán claves separadas.

El formato básico del comando ara firmar la clave pública de usuario para crear el certificado de usuario es como sigue:

ssh-keygen -s ca_user_key -I certificate_ID id_rsa.pub

Donde -s indica la clave privada usada para firmar el certificado, -I indica una cadena de identidad, la certificate_ID, que puede ser cualquier valor alfanumérico. Está almacenada como una cadena terminada en cero en el certificado. La certificate_ID se registra cada vez que se usa el certificado para la identificación y también se usa cuando se revoca el certificado. Teniendo un valor largo hace que los registros sean más difíciles de leer, por lo tanto, usar el nombre de host para los certificados de host y el nombre de usuario para los certitfivcados de usuario es una opción segura.

Para firmar una clave pública de host para crear un certificado de host, añada la opción -h:

ssh-keygen -s ca_host_key -I certificate_ID -h ssh_host_rsa_key.pub

Las claves de host son generadas por el sistema de modo predeterminado, para listar las claves, introduzca el siguiente comando:

~]# ls -l /etc/ssh/ssh_host*
-rw-------. 1 root root  668 Jul  9  2014 /etc/ssh/ssh_host_dsa_key
-rw-r--r--. 1 root root  590 Jul  9  2014 /etc/ssh/ssh_host_dsa_key.pub
-rw-------. 1 root root  963 Jul  9  2014 /etc/ssh/ssh_host_key
-rw-r--r--. 1 root root  627 Jul  9  2014 /etc/ssh/ssh_host_key.pub
-rw-------. 1 root root 1671 Jul  9  2014 /etc/ssh/ssh_host_rsa_key
-rw-r--r--. 1 root root  382 Jul  9  2014 /etc/ssh/ssh_host_rsa_key.pub

It is recommended to create and store CA keys in a safe place just as with any other private key. In these examples the root user will be used. In a real production environment using an offline computer with an administrative user account is recommended. For guidance on key lengths see NIST Special Publication 800-131A Revision 1.

Generación de Claves de Firma de Certificado SSH CA

En el servidor designado para ser la CA, genere dos claves para su uso en la firma de certificados. Estas son las claves en las que los demás host necesitan confiar. Elija nombres adecuados, por ejemplo ca_user_key y ca_host_key. Para generar la clave de firma del certificado de usuario, introduzca el siguiente comando como root:

~]# ssh-keygen -t rsa -f ~/.ssh/ca_user_key
Generating public/private rsa key pair.
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/ca_user_key.
Your public key has been saved in /root/.ssh/ca_user_key.pub.
The key fingerprint is:
11:14:2f:32:fd:5d:f5:e4:7a:5a:d6:b6:a0:62:c9:1f root@host_name.example.com
The key's randomart image is:
+--[ RSA 2048]----+
|       .+.      o|
|       . o     +.|
|      o + .   . o|
|       o + . . ..|
|        S . ... *|
|        . . . .*.|
|         = E  .. |
|        . o .    |
|           .     |
+-----------------+

Genere una clave de firma de certificado de host, ca_host_key, como sigue:

~]# ssh-keygen -t rsa -f ~/.ssh/ca_host_key
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/ca_host_key.
Your public key has been saved in /root/.ssh/ca_host_key.pub.
The key fingerprint is:
e4:d5:d1:4f:6b:fd:a2:e3:4e:5a:73:52:91:0b:b7:7a root@host_name.example.com
The key's randomart image is:
+--[ RSA 2048]----+
|            ..   |
|           . ....|
|        . . o +oo|
|       o .   o *o|
|        S     = .|
|             o. .|
|            *.E. |
|           +o=   |
|          .oo.   |
+-----------------+

Si se requiere, confirme que los permisos son los correctos:

~]# ls -la ~/.ssh
total 40
drwxrwxrwx. 2 root root 4096 May 22 13:18 .
dr-xr-x---. 3 root root 4096 May  8 08:34 ..
-rw-------. 1 root root 1743 May 22 13:15 ca_host_key
-rw-r--r--. 1 root root  420 May 22 13:15 ca_host_key.pub
-rw-------. 1 root root 1743 May 22 13:14 ca_user_key
-rw-r--r--. 1 root root  420 May 22 13:14 ca_user_key.pub
-rw-r--r--. 1 root root  854 May  8 05:55 known_hosts
-r--------. 1 root root 1671 May  6 17:13 ssh_host_rsa
-rw-r--r--. 1 root root 1370 May  7 14:30 ssh_host_rsa-cert.pub
-rw-------. 1 root root  420 May  6 17:13 ssh_host_rsa.pub

Crear la CA propia de servidor para certificado de host firmando la clave pública de host de servidor junto con una cadena de identificación como el nombre del host, el nombre de dominio totalmente cualificado (FQDN) de la CA de servidor pero sin el . final y un período de validez. El comando tiene el siguiente formato:
```
ssh-keygen -s ~/.ssh/ca_host_key -I certificate_ID -h -n host_name.example.com -V -start:+end /etc/ssh/ssh_host_rsa.pub
```
La opción -n restringe este certificado a un host específico dentro del dominio. La opción -V es para añadir un período de validez; esto es altamente recomendable. Donde el período de validez se pretende que sea un año, cincuenta y dos semanas, considere la necesidad de tiempo para cambiar los certificados y cualquier período de vacaciones alrededor de la fecha de expiración del mismo.

Por ejemplo:
```
~]# ssh-keygen -s ~/.ssh/ca_host_key -I host_name -h -n host_name.example.com -V -1w:+54w5d /etc/ssh/ssh_host_rsa.pub
Enter passphrase:
Signed host key /root/.ssh/ssh_host_rsa-cert.pub: id "host_name" serial 0 for host_name.example.com valid from 2015-05-15T13:52:29 to 2016-06-08T13:52:29
```

Distribuyendo y Confiando en las Claves Públicas SSH

Los hosts que deben permitir el inicio de sesión autenticado por certificado de los usuarios deben configurarse para confiar en la clave pública de CA que se utiliza para firmar los certificados de usuario, con el objetivo de autenticar los certificados de usuario. En este ejemplo esto es la ca_user_key.pub.

Publicar la clave ca_user_key.pub y descargarla en todos los host en los que se requiera para permitir el inicio de sesión remoto de los usuarios. Alternativamente, copie la clave pública CA de usuario en todos los hosts. En un entorno en producción, considere copiar la clave pública en una cuenta de administrador primero. El comando de copia segura puede ser usado para copiar la clave pública en los hosts remotos. El comando tiene el siguiente formato:

scp  ~/.ssh/ca_user_key.pub root@host_name.example.com:/etc/ssh/

Donde host_name es el nombre de host de un servidor que es requerido para autenticar los certificados de usuario presentados donde el proceso de inicio de sesión. Esté seguro de copia la clave pública no la clave privada. Por ejemplo, como root:

~]# scp ~/.ssh/ca_user_key.pub root@host_name.example.com:/etc/ssh/
The authenticity of host 'host_name.example.com (10.34.74.56)' can't be established.
RSA key fingerprint is fc:23:ad:ae:10:6f:d1:a1:67:ee:b1:d5:37:d4:b0:2f.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'host_name.example.com,10.34.74.56' (RSA) to the list of known hosts.
root@host_name.example.com's password:
ca_user_key.pub                                       100%  420     0.4KB/s   00:00

Para la autenticación del usuario remoto las claves CA pueden ser marcadas como de confianza por usuario en el archivo ~/.ssh/authorized_keys usando la directiva cert-authority o para uso global por los principios de la directiva TrustedUserCAKeys en el archivo /etc/ssh/sshd_config. Para la autenticación de los host remotos, las claves CA se pueden marcar como de confianza globalmente en el archivo /etc/ssh/known_hosts o por usuario en el archivo ~/.ssh/ssh_known_hosts.

Confiar en la Clave de Firma del Usuario

Para certificados de usuario que tienen uno o más principios enumerados y donde la configuración debe tener un efecto global, edite el archivo /etc/ssh/sshd_config como sigue:
```
TrustedUserCAKeys /etc/ssh/ca_user_key.pub
```
Reinicie sshd para hacer que los cambios tengan efecto:
```
~]# service sshd restart
```

Para evitar que se le presente una advertencia sobre un host desconocido el sistema de un usuario debe confiar en la clave pública de CA que se utilizó para firmar los certificados de host. En este ejemplo esta es ca_host_key.pub.

Confiar en la Clave de Firma de Host

Extraer los contenidos de la clave pública usada para firmar el certificado de host. Por ejemplo, en la CA:
```
cat ~/.ssh/ca_host_key.pub
ssh-rsa  AAAAB5Wm.== root@ca-server.example.com
```
Para configurar que los sistemas clientes confíen en los certificados de host firmados del servidor, añada los contenidos de ca_host_key.pub`en el archivo global `known_hosts. Esto verificará automáticamente el certificado anunciado del host servidor contra la clave pública de CA para todos los usuarios cada vez que una nueva máquina se conecte al dominio *.example.com. Acceda como root y configura el archivo `/etc/ssh/ssh_known_hosts`como sigue:
```
~]# vi /etc/ssh/ssh_known_hosts
# A CA key, accepted for any host in *.example.com
@cert-authority *.example.com ssh-rsa AAAAB5Wm.
```
Donde ssh-rsa AAAAB5Wm. son los contenidos de ca_host_key.pub. Lo anterior configura el sistema para confiar en la pública de los hosts servidores. Esto habilita la autenticación global de los certificados presentados por los hosts a los usuarios remotos.

Crear Certificados SSH

Un certificado es una clave pública firmada. Las claves públicas de usuario y de host deben ser copiadas en el servidor CA para firmar con la clave privada del servidor CA.

La copia de muchas claves en el servidor CA para ser firmadas puede crear confusión sí no se las ha denominado con un nombre único. Si se usa siempre el nombre predeterminado para la última clave que se copie esto sobrescribirá la clave copiada previamente, lo que puede ser un buen método para un administrador. En el ejemplo de abajo se usa el nombre predeterminado. En un entorno en producción, considere la utilización de nombres fácilmente reconocibles. Se recomienda tener un directorio dedicado en el servidor CA de propiedad de un usuario administrador para copiar en él las claves. No se recomienda copiar estas claves en el directorio /etc/ssh/ del usuario root. En los ejemplos de abajo se usará una cuenta llamada admin con un directorio llamado `keys/.

Crear una cuenta de administrador, en este ejemplo admin y un directorio para recibir las claves de usuario. Por ejemplo:

~]$ mkdir keys

Establecer los permisos para permitir que se copien las claves en él:

~]$ chmod o+w keys
ls -la keys
total 8
drwxrwxrwx. 2 admin admin 4096 May 22 16:17 .
drwx------. 3 admin admin 4096 May 22 16:17 ..

Crear Certificados SSH para Autenticar Hosts

El comando para firmar un certificado de host tiene el siguiente formato:

ssh-keygen -s ca_host_key -I host_name -h ssh_host_rsa_key.pub

El certificado de host se denominará ssh_host_rsa_key-cert.pub.

Generar un Certificado de Host

Para autenticar un host a un usuario se debe generar una clave pública en el host, pasarla al servidor CA, ser firmada por la CA y después devolverla para ser almacenada en el host para presentarse a un usuario que intente acceder al host.

Las claves de host son generadas automáticamente en el sistema. Para listarlas introduzca el siguiente comando:

~]# ls -l /etc/ssh/ssh_host*
-rw-------. 1 root root  668 May  6 14:38 /etc/ssh/ssh_host_dsa_key
-rw-r--r--. 1 root root  590 May  6 14:38 /etc/ssh/ssh_host_dsa_key.pub
-rw-------. 1 root root  963 May  6 14:38 /etc/ssh/ssh_host_key
-rw-r--r--. 1 root root  627 May  6 14:38 /etc/ssh/ssh_host_key.pub
-rw-------. 1 root root 1679 May  6 14:38 /etc/ssh/ssh_host_rsa_key
-rw-r--r--. 1 root root  382 May  6 14:38 /etc/ssh/ssh_host_rsa_key.pub

Copie la clave pública elegida en el servidor designado como CA. Por ejemplo, desde el host:

~]# scp /etc/ssh/ssh_host_rsa_key.pub admin@ca-server.example.com:~/keys/ssh_host_rsa_key.pub
The authenticity of host 'ca-server.example.com (10.34.74.58)' can't be established.
RSA key fingerprint is b0:e5:ea:b8:75:e2:f0:b1:fe:5b:07:39:7f:58:64:d9.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'ca-server.example.com,10.34.74.58' (RSA) to the list of known hosts.
admin@ca-server.example.com's password:
ssh_host_rsa_key.pub                           100%  382     0.4KB/s   00:00

Alternativamente desde la CA:

~]$ scp  root@host_name.example.com:/etc/ssh/ssh_host_rsa_key.pub ~/keys/ssh_host_rsa_key.pub

En el servidor CA firme la clave pública de host. Por ejemplo, como root:

~]# ssh-keygen -s ~/.ssh/ca_host_key -I host_name -h -n host_name.example.com -V -1d:+54w /home/admin/keys/ssh_host_rsa_key.pub
Enter passphrase:
Signed host key /home/admin/keys/ssh_host_rsa_key-cert.pub: id "host_name" serial 0 for host_name.example.com valid from 2015-05-26T12:21:54 to 2016-06-08T12:21:54

Donde host_name es el nombre de host del sistema que requiere el certificado.

Copiar el certificado al host. Por ejemplo, desde la CA:

~]# scp /home/admin/keys/ssh_host_rsa_key-cert.pub root@host_name.example.com:/etc/ssh/
root@host_name.example.com's password:
ssh_host_rsa_key-cert.pub                      100% 1384     1.5KB/s   00:00

Configurar el host para presentar el certificado al sistema del usuario cuando un usuario inicia el proceso de acceso. Como root, edite el archivo /etc/ssh/sshd_config como sigue:
```
HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub
```
Reinicie sshd para hacer que los cambios tengan efecto:
```
~]# service sshd restart
```
En el sistema del usuario, quite las claves que pertenecen a los hosts del archivo ~/.ssh/known_hosts si el usuario ha accedido previamente al host configurado arriba. Cuando un usuario accede a un host no se le presentará más veces la advertencia sobre la autenticidad de hosts.

To test the host certificate, on a client system, ensure the client has set up the global /etc/ssh/known_hosts file, as described in Trusting the Host Signing Key, and that the server’s public key is not in the ~/.ssh/known_hosts file. Then attempt to log into the server over SSH as a remote user. You should not see a warning about the authenticity of the host. If required, add the -v option to the SSH command to see logging information.

Crear Certificados SSH para Usuarios Autenticados

Para firmar un certificado de usuario, utilice un comando con el siguiente formato:

ssh-keygen -s ca_user_key -I user_name -n user_name -V -start:+end id_rsa.pub

El certificado resultante se denominará id_rsa-cert.pub.

El comportamiento predeterminado de OpenSSH es que un usuario tiene permitido acceder como usuario remoto sí uno de los principales especificados en el certificado coinciden con el nombre del usuario remoto. Esto se puede ajustar de las siguientes maneras:

Añadir más nombres de usuario al certificado durante el proceso de firma usando la opción -n:
```
-n "name1[,name2,...]"
```
En el sistema del usuario, añadir la clave pública de la CA en el archivo ~/.ssh/authorized_keys usando la directiva cert-authority y listando los nombres de los principales como sigue:
```
~]# vi ~/.ssh/authorized_keys
# A CA key, accepted for any host in *.example.com
@cert-authority principals="name1,name2" *.example.com ssh-rsa AAAAB5Wm.
```
En el servidor, crear un archivo AuthorizedPrincipalsFile bien por usuario o globalmente y añadir los nombres de los principales al archivo para aquellos usuarios que tengan permitido acceder. Después en el archivo /etc/ssh/sshd_config, especificar el archivo usando la directiva AuthorizedPrincipalsFile.

Generar un Certificado de Usuario

Para autenticar un usuario en un host remoto se debe generar una clave pública por usuario, pasarla al servidor CA, firmarla por la CA y devolverla después para ser almacenada por el usuario para su utilización cuando acceda a un host.

Sobre los sistemas cliente, acceder como el usuario que requiere el certificado. Comprobar las claves disponibles como sigue:

~]$ ls -l ~/.ssh/

Si no existe una clave pública adecuada, genere una y establezca los permisos del directorio sí el directorio no es el directorio predeterminado. Por ejemplo, introduzca el siguiente comando:

~]$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user1/.ssh/id_rsa):
Created directory '/home/user1/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user1/.ssh/id_rsa.
Your public key has been saved in /home/user1/.ssh/id_rsa.pub.
The key fingerprint is:
b1:f8:26:a7:46:87:c3:60:54:a3:6d:85:0d:60:fe:ce user1@host1.example.com
The key's randomart image is:
+--[ RSA 2048]----+
|    oo++.        |
|   o.o.o.        |
|   .o o .        |
|    oo . o       |
|   . oo.S        |
|     o=..        |
|     .Eo+        |
|      .=         |
|     ..          |
+-----------------+

De modo predeterminado los permisos para una clave de usuario son drwx------. o en octal 0700. Si se requiere confirmar que los permisos son los correctos:

~]$ ls -la ~/.ssh
total 16
drwx------. 2 user1 user1 4096 May  7 12:37 .
drwx------. 3 user1 user1 4096 May  7 12:37 ..
-rw-------. 1 user1 user1 1679 May  7 12:37 id_rsa
-rw-r--r--. 1 user1 user1  421 May  7 12:37 id_rsa.pub

See Using Key-based Authentication for more examples of key generation and for instructions on setting the correct directory permissions.

La clave pública elegida debe ser copiada en el servidor designado como CA con el objetivo de que sea firmada. El comando de copia segura puede ser utilizado para hacer esto, el comando tiene el siguiente formato:
```
scp  ~/.ssh/id_protocol.pub admin@ca_server.example.com:~/keys/
```
Donde protocol es la parte del nombre e archivo que indica el protocolo usado para generar la clave key, por ejemplo rsa, admin es una cuenta en el servidor CA y /keys/ es un directorio configurado para recibir las claves a ser firmadas.

Copie la clave pública elegida en el servidor designado como CA. Por ejemplo:
```
~]$ scp ~/.ssh/id_rsa.pub admin@ca-server.example.com:~/keys/
admin@ca-server.example.com's password:
id_rsa.pub                                  100%  421     0.4KB/s   00:00
```
If you have configured the client system to trust the host signing key as described in Trusting the Host Signing Key then you should not see a warning about the authenticity of the remote host.

En el servidor CA, firmar la clave pública de usuario. Por ejemplo, como root:

~]# ssh-keygen -s ~/.ssh/ca_user_key -I user1 -n user1 -V -1d:+54w /home/admin/keys/id_rsa.pub
Enter passphrase:
Signed user key /home/admin/keys/id_rsa-cert.pub: id "user1" serial 0 for host_name.example.com valid from 2015-05-21T16:43:17 to 2016-06-03T16:43:17

Copie el certificado resultante en el directorio ~/.ssh/ del usuario en su sistema. Por ejemplo:

~]# scp /home/admin/keys/id_rsa-cert.pub user1@host_name.example.com:~/.ssh/
user1@host_name.example.com's password:
id_rsa-cert.pub                             100%  1498    1.5KB/s   00:00

Sí utiliza los nombres y localizaciones de archivos estándar no se requiere más configuración puesto que el demonio SSH buscará los certificados de usuario que terminen en -cert.pub ay los usará automáticamente sí los encuentra. Tenga en cuenta que la localización y los nombres de archivos para las claves SSH versión 2 son: ~/.ssh/id_dsa, ~/.ssh/id_ecdsa y ~/.ssh/id_rsa`como se explica en la página de manual `ssh_config(5). Sí utiliza estas convenciones de localizaciones y nombres no necesita editar los archivos de configuración para habilitar que sshd presente el certificado. Se usarán automáticamente cuando acceda a un sistema remoto. Sí este es el caso salte al paso 6.

Si se requiere usar un directorio que no sea el predeterminado o la denominación de archivos convencional, entonces como root añada la siguiente línea en los archivos /etc/ssh/ssh_config o ~/.ssh/config:
```
IdentityFile ~/path/key_file
```
Tenga en cuenta que esto debe ser el nombre de la clave privada, no tiene .pub o -cert.pub. Asegure que los permisos del archivo son los correctos. Por ejemplo:
```
~]$ ls -la ~/.ssh/config
-rw-rw-r--. 1 user1 user1 36 May 27 21:49 /home/user1/.ssh/config
chmod 700 ~/.ssh/config
~]$ ls -la ~/.ssh/config
-rwx------. 1 user1 user1 36 May 27 21:49 /home/user1/.ssh/config
```
Esto habilitará al usuario de este sistema para ser autenticados por un certificado de usuario cuando acceda a un sistema remoto configurado para confiar en la clave del certificado de usuario firmado por la CA.
Para probar el certificado de usuario, intente acceder al servidor sobre SSH desde la cuenta del usuario. Debería hacer esto como un usuario listado como principal en el certificado, si hay alguno especificado. No se le debería pedir contraseña. Si se requiere, añada la opción -v al comando SSH para ver la información de registro.

Firmar un Certificado SSH Utilizando un Token PKCS#11

Es posible firmar una clave de host utilizando una clave CA almacenada en un token PKCS#11 proporcionando la librería de tokens usando la opción -D e identificando la clave de la CA proporcionando la mitad pública como argumento a la opción -s:

ssh-keygen -s ca_host_key.pub -D libpkcs11.so -I certificate_ID host_key.pub

En todos los casos certificate_ID es un "identificador de clave" que registra el servidor cuando se usa el certificado para autenticarse.

Los certificados se pueden configurar para ser válidos solo para un conjunto de usuarios o nombres de host, los principales. De modo predeterminado, los certificados generados son válidos para todos los usuarios u hosts. Para generar un certificado para un conjunto especificado de principales, use una lista separada por comas con la opción -n como sigue:

ssh-keygen -s ca_user_key.pub -D libpkcs11.so -I certificate_ID -n user1,user2 id_rsa.pub

y para hosts:

ssh-keygen -s ca_host_key.pub -D libpkcs11.so -I certificate_ID -h -n host.domain ssh_host_rsa_key.pub

Limitaciones adicionales sobre la validez y el uso de los certificados de usuarios se pueden especificar a través de las opciones de certificado. Una opción de certificado puede deshabilitar funciones de la sesión SSH, puede ser válido solo cuando se presenta desde unas direcciones fuente concreta o pueden forzar el uso de comandos específicos. Una lista de las opciones válidas de certificado se puede ver en la página de manual ssh-keygen(1) para la opción -O.

Los certificados pueden ser definidos para ser válidos durante un tiempo de vida específico. La opción -V permite especificar los tiempos de inicio y fin del certificado. Por ejemplo:

ssh-keygen -s ca_user_key -I certificate_ID id_rsa.pub -V "-1w:+54w5d"

Un certificado que se presente en un tiempo fuera de este rango no será considerado válido. De modo predeterminado, los certificados son válidos indefinidamente desde UNIX Epoch.

Visualización de un Certificado SSH CA

Para visualizar un certificado, utilice la -L para listar los contenidos. Por ejemplo, para un certificado de usuario:

~]$ ssh-keygen -L -f ~/.ssh/id_rsa-cert.pub
/home/user1/.ssh/id_rsa-cert.pub:
        Type: ssh-rsa-cert-v01@openssh.com user certificate
        Public key: RSA-CERT 3c:9d:42:ed:65:b6:0f:18:bf:52:77:c6:02:0e:e5:86
        Signing CA: RSA b1:8e:0b:ce:fe:1b:67:59:f1:74:cd:32:af:5f:c6:e8
        Key ID: "user1"
        Serial: 0
        Valid: from 2015-05-27T00:09:16 to 2016-06-09T00:09:16
        Principals:
                user1
        Critical Options: (none)
        Extensions:
                permit-X11-forwarding
                permit-agent-forwarding
                permit-port-forwarding
                permit-pty
                permit-user-rc

Para visualizar un certificado de host:

~]# ssh-keygen -L -f /etc/ssh/ssh_host_rsa_key-cert.pub
/etc/ssh/ssh_host_rsa_key-cert.pub:
        Type: ssh-rsa-cert-v01@openssh.com host certificate
        Public key: RSA-CERT 1d:71:61:50:05:9b:ec:64:34:27:a5:cc:67:24:03:23
        Signing CA: RSA e4:d5:d1:4f:6b:fd:a2:e3:4e:5a:73:52:91:0b:b7:7a
        Key ID: "host_name"
        Serial: 0
        Valid: from 2015-05-26T17:19:01 to 2016-06-08T17:19:01
        Principals:
                host_name.example.com
        Critical Options: (none)
        Extensions: (none)

Revocar un certificado SSH CA

Si un certificado es robado debería ser revocado. Aunque OpenSSH no proporciona un mecanismo para distribuir la lista de revocación es bastante fácil crear la lista de revocación y distribuirla por otros medios en lugar de cambiar las claves CA y los certificados de todos los host y usuarios previamente creados y distribuidos.

Las claves se pueden revocar añadiéndolas al archivo revoked_keys y especificando el nombre del archivo en el archivo sshd_config como sigue:

RevokedKeys /etc/ssh/revoked_keys

Tenga en cuenta que este archivo no se puede leer, se rechazará la autenticación de clave pública de todos los usuarios.

Una lista nueva de revocación de claves puede ser generada como sigue:

~]$ ssh-keygen -kf  /etc/ssh/revoked_keys -z 1 ~/.ssh/id_rsa.pub

Para añadir líneas a la lista use la opción -u para actualizar la lista:

ssh-keygen -ukf /etc/ssh/revoked_keys -z integer ~/.ssh/id_rsa.pub

donde integer es el número de línea.

Para probar si la clave ha sido revocada, consulte en la lista de revocación la presencia de la clave. Utilice un comando como el siguiente:

ssh-keygen -Qf  /etc/ssh/revoked_keys ~/.ssh/id_rsa.pub

Un usuario puede revocar un certificado CA cambiando la directiva cert-authority para revocarla en el archivo known_hosts.

Clientes OpenSSH

Asegúrese de tener instalados los paquetes relevantes

Para conectar a un servidor OpenSSH desde una máquina cliente, debe tener instalado el paquete openssh-clients. Vea en Instalando Paquetes más información sobre como instalar nuevos paquetes en Fedora Rawhide.

Usar la Utilidad ssh

La utilidad ssh le permite acceder a una máquina remota y ejecutar comandos allí. En un sustituto seguro de los programas rlogin, rsh y telnet.

De forma parecida al comando telnet accede a una máquina remota usando el siguiente comando:

ssh hostname

Por ejemplo, para acceder a una máquina remota llamada penguin.example.com, teclee el siguiente comando en el símbolo del sistema:

~]$ ssh penguin.example.com

Esto le dará acceso con el mismo nombre de usuario que está utilizando en la máquina local. S desea especificar un nombre de usuario diferente, utilice un comando con el siguiente formato:

ssh username@hostname

Por ejemplo para acceder a penguin.example.com como USER, teclee:

~]$ ssh USER@penguin.example.com

La primera vez que inicie una conexión se le presentará un mensaje similar a este:

The authenticity of host 'penguin.example.com' can't be established.
ECDSA key fingerprint is 256 da:24:43:0b:2e:c1:3f:a1:84:13:92:01:52:b4:84:ff.
Are you sure you want to continue connecting (yes/no)?

Los usuarios deberían siempre comprobar que la huella digital es correcta antes de responder a la pregunta de ese diálogo. El usuario puede consultar con el administrador del servidor para confirmar que la clave es la correcta. Esto se debería hacer de una forma segura y previamente acordada. Si el usuario tiene acceso a las claves de host del servidor, la huella digital se puede comprobar utilizando el comando ssh-keygen como sigue:

~]# ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub
256 da:24:43:0b:2e:c1:3f:a1:84:13:92:01:52:b4:84:ff   (ECDSA)

Teclee yes para aceptar la clave y confirmar la conexión. Verá un aviso de que el servidor ha sido añadido a la lista de hosts conocidos y se le pedirá su contraseña:

Warning: Permanently added 'penguin.example.com' (ECDSA) to the list of known hosts.
USER@penguin.example.com's password:

Actualizar la clave de host de un servidor SSH

Si la clave de host del servidor SSH cambia, el cliente notifica al usuario que la conexión no se puede efectuar hasta que la clave de host del servidor sea borrada del archivo ~/.ssh/known_hosts. Antes de hacer esto, sin embargo, contacte con el administrador de sistemas del servidor SSH para verificar que el servidor no ha sido comprometido.

Para quitar una clave del archivo ~/.ssh/known_hosts, envíe un comando como el siguiente:

~]# ssh-keygen -R penguin.example.com
# Host penguin.example.com found: line 15 type ECDSA
/home/USER/.ssh/known_hosts updated.
Original contents retained as /home/USER/.ssh/known_hosts.old

Después de introducir la contraseña, se le proporcionará un indicador de shell para la máquina remota.

Alternativamente, se puede utilizar el programa ssh para ejecutar un comando en la máquna remota sin acceder a un indicador de shell:

ssh username@hostname command

Por ejemplo, el archivo /etc/redhat-release proporciona información sobre la versión de Fedora . Para ver los contenidos de este archivo en penguin.example.com, teclee:

~]$ ssh USER@penguin.example.com cat /etc/redhat-release
USER@penguin.example.com's password:
Fedora release 20 (Heisenbug)

Después de que introduzca la contraseña correcta, se le mostrará el nombre de usuario y volverá a su indicador de shell local.

Usar la Utilidad scp

scp se puede usar para transferir archivos entre máquinas sobre una conexión segura, encriptada. En su diseño es muy similar a rcp.

Para transferir un archivo local a un sistema remoto, utilice un comando con el siguiente formato:

scp localfile username@hostname:remotefile

Por ejemplo, s desea transferir taglist.vim a una máquina remota llamada penguin.example.com,teclee lo siguiente en el indicador de shell:

~]$ scp taglist.vim USER@penguin.example.com:.vim/plugin/taglist.vim
USER@penguin.example.com's password:
taglist.vim                                   100%  144KB 144.5KB/s   00:00

Se pueden especificar múltiples archivos de una vez. Para transferir los contenidos de .vim/plugin/ al mismo directorio en la máquina remota penguin.example.com, teclee el siguiente comando:

~]$ scp .vim/plugin/* USER@penguin.example.com:.vim/plugin/
USER@penguin.example.com's password:
closetag.vim                                  100%   13KB  12.6KB/s   00:00
snippetsEmu.vim                               100%   33KB  33.1KB/s   00:00
taglist.vim                                   100%  144KB 144.5KB/s   00:00

Para transferir un archivo remoto al sistema local, utilice la siguiente sintaxis:

scp username@hostname:remotefile localfile

Por ejemplo, para descargar el archivo de configuración .vimrc desde la máquina remota, teclee:

~]$ scp USER@penguin.example.com:.vimrc .vimrc
USER@penguin.example.com's password:
.vimrc                                        100% 2233     2.2KB/s   00:00

Usar la Utilidad sftp

The sftp utility can be used to open a secure, interactive FTP session. In its design, it is similar to ftp except that it uses a secure, encrypted connection.

Para conectar a un sistema remoto, utilice un comando con el siguiente formato:

sftp username@hostname

Por ejemplo, para acceder a una máquina remota llamada penguin.example.com con el nombre de usuario USER teclee:

~]$ sftp USER@penguin.example.com
USER@penguin.example.com's password:
Connected to penguin.example.com.
sftp>

Después de introducir la contraseña correcta, se le presentará un indicador. La utilidad sftp acepta un conjunto de comandos similares a los usados por ftp (vea A selection of available sftp commands).

Table 3. Una selección de los comandos sftp disponibles
Command	Description
ls [directory]	List the content of a remote directory. If none is supplied, a current working directory is used by default.
cd directory	Change the remote working directory to directory.
mkdir directory	Create a remote directory.
rmdir path	Remove a remote directory.
put localfile [remotefile]	Transfer localfile to a remote machine.
get remotefile [localfile]	Transfer remotefile from a remote machine.

Para una lista completa de los comandos disponibles, vea la página de manual sftp(1).

Más Que una Shell Segura

Una interfaz de línea de comando segura es justo el principio de las muchas maneras en que ser puede usar SSH. Teniendo la cantidad apropiada de ancho de banda, las sesiones X11 se pueden llevar directamente sobre un canal SSH. O, utilizando el envío TCP/IP, los anteriormente conexiones inseguras de puertos entre sistemas se pueden mapear a canales SSH específicos.

Reenvío X11

Para abrir una sesión X11 sobre una conexión SSH, use un comando en el siguiente formato:

ssh -Y username@hostname

Por ejemplo, para acceder a una máquina remota llamada penguin.example.com con el nombre de usuario USER teclee:

~]$ ssh -Y USER@penguin.example.com
USER@penguin.example.com's password:

Cuando un programa X está corriendo sobre un indicador de shell seguro, el cliente SSH y el servidor crean un nuevo canal seguro y los datos del programa X son sobre este canal a la máquina cliente transparentemente.

Tenga en cuenta que el sistema X Window debe ser instalado en el sistema remoto antes de que pueda tener lugar el reenvío. Introduzca el siguiente comando como root para el instalar el grupo de paquete X11:

~]# dnf group install "X Window System"

El reenvío X11 puede ser muy útil. Por ejemplo, se puede usar el reenvío X11 para crear una sesión segura e interactiva de la utilidad Ajustes de Impresión. Para hacer esto, conecte con el servidor usando ssh y teclee:

~]$ system-config-printer &

Aparecerá la herramienta Ajustes de Impresión permitiendo al usuario remoto configurar con seguridad la impresión en el sistema remoto.

Reenvío de Puertos

SSH puede asegurar los, de otro modo, inseguros protocolos TCP/IP por medio del reenvío de puertos. Cuando se utiliza esta técnica el servidor SSH se convierte en un conducto encriptado para el cliente SSH.

El reenvío de puertos trabaja mapeando un puerto local en el cliente con un puerto remoto en el servidor. SSH puede mapear cualquier puerto del servidor con cualquier puerto del cliente. No es necesario que los números de puerto coincidan para que la técnica funcione.

Usar números de puertos reservados

La configuración del reenvío de puertos para que escuchen en puertos por debajo del 1024 requiere acceso a nivel de root.

Para crear un canal de reenvío de puertos TCP/IP pque escuche las conexiones en el localhost, use un comando con el siguiente formato:

ssh -L local-port:remote-hostname:remote-port username@hostname

Por ejemplo, para comprobar el correo electrónico en un servidor llamado mail.example.com utilizando POP3 a través de una conexión encriptada use el siguiente comando:

~]$ ssh -L 1100:mail.example.com:110 mail.example.com

Una vez que el canal de reenvío de puerto está establecido entre la máquina cliente y el servidor de correo , dirige a un cliente de correo POP3 para usar el puerto 1100 en el localhost para que compruebe el nuevo correo electrónico. Cualquier petición enviada al puerto 1100 en el sistema cliente será dirigida seguramente a servidor mail.example.com.

Sí mail.example.com no está corriendo en un servidor SSH pero está en otra máquina en la misma red, SSH se puede usar aún como parte segura de la conexión. Sin embargo, es necesario un comando ligeramente diferente:

~]$ ssh -L 1100:mail.example.com:110 other.example.com

En este ejemplo, las peticiones POP3 desde el puerto 1100 en la máquina cliente son reenviadas a través de la conexión sobre el puerto 22 al servidor other.example.com. Después other.example.com conecta al puerto 110 de mail.example.com para comprobar el correo electrónico nuevo. Tenga en cuenta que usando esta técnica solo es segura la conexión entre el sistema cliente y el servidor SSH other.example.com.

El reenvío de puertos se puede usar también para obtener información de forma segura a través de los cortafuegos de red. Si el cortafuegos está configurado para permite el tráfico SSH por medio de su puerto estándar (esto es, puerto 22) pero bloquea el acceso a los otros puertos, es todavía posible una conexión entre dos hosts usando ls puertos bloqueados redirigiendo su comunicación sobre una conexión SSH establecida.

Una conexión es solo tan segura como un sistema cliente

La utilización del reenvío de puertos para reenviar conexiones de esta manera permite a cualquier usuario en el sistema cliente conectar con este servicio. Si el sistema cliente se ve comprometido, el atacante tiene también acceso a los servicios reenviados.

Los administradores de sistema preocupados por el reenvío de puertos pueden deshabilitar esta funcionalidad especificando un parámetro No para la línea AllowTcpForwarding en /etc/ssh/sshd_config y reiniciando el servicio sshd.

Recursos Adicionales

Para más información sobre como configurar o conectar a un servidor OpenSSH en Fedora, vea los recursos listados abajo.

Documentación Instalada

sshd(8) — La página de manual para el demonio sshd documenta las opciones de linea de comandos disponibles y proporciona una lista completa de los archivos y directorios de configuración soportados.
ssh(1) — La página de manual para la aplicación cliente ssh proporciona una lista completa de las opciones de línea de comandos disponibles y los archivos y directorios soportados.
scp(1) — La página de manual para utilidad scp proporciona una descripción detallada de esta utilidad y su utilización.
sftp(1) — La página de manual para la utilidad sftp.
ssh-keygen(1) — La página de manual para la utilidad ssh-keygen documenta en detalla como usarla para generar, administrar y convertir las claves de autenticación usadas por ssh.
ssh_config(5) — La página de manual denominada ssh_config documenta las opciones de configuración del cliente SSH disponibles.
sshd_config(5) — La página de manual denominada sshd_config proporciona una total descripción de las opciones de configuración del demonio SSH disponibles.

Documentación el Línea

OpenSSH Home Page — The OpenSSH home page containing further documentation, frequently asked questions, links to the mailing lists, bug reports, and other useful resources.
OpenSSL Home Page — The OpenSSL home page containing further documentation, frequently asked questions, links to the mailing lists, and other useful resources.

1. Una conexión multiplexada consta de diversas señales que son enviadas sobre un medio común compartido. Con SSH, los diferentes canales se envían sobre una conexión común protegida.

Want to help? Learn how to contribute to Fedora Docs ›