OpenSSH

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:

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.

El protocolo SSH suministra las siguientes salvaguardias:

Adicionalmente, también ofrece las siguientes opciones:

Actualmente existen dos variedades de SSH: versión 1 y versión 2. La suite OpenSSH bajo Fedora utiliza SSH versión 2, que tiene un algoritmo de intercambio de clave mejorado no vulnerable a las vulnerabilidades conocidas en versión 1. El protocolo versión 1 ha sido quitado de la suite OpenSSH y no se soporta ya.

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

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.

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).

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

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

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

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:

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.

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:

Para deshabilitar que corran estos servicios en el arranque teclee:

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

Para mejorar la seguridad del sistema aún más genere los pares de claves SSH y después fuerce la autenticación basada en clave deshabilitando la autenticación por contraseña. Para hacerlo, cree un archivo de configuración desplegable, por ejemplo /etc/ssh/sshd_config.d/01-local.conf. Asegúrese de que esté lexicográficamente antes del archivo 50-redhat.conf, proporcionando los valores predeterminados de Fedora. En un editor de texto como vi o nano inserte la opción PasswordAuthentication como sigue:

Si está trabajando en un sistema que no sea una nueva instalación predeterminada, compruebe que PubkeyAuthentication no no ha sido establecida ni en /etc/ssh/sshd_config ni en ningún archivo incluido en el directorio desplegable. Si se conecta remotamente, no usando consola o acceso fuera de banda, pruebe el acceso basado en clave en ejecución antes de deshabilitar la autenticación por contraseña.

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 34 utiliza SSH Protocol 2 y claves RSA de modo predeterminado (vea más información en see Versiones del Protocolo).

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.

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:

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:

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:

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

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:

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:

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.

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.

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.

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

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

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:

In all cases, certificate_ID is a "key identifier" that is logged by the server when the certificate is used for authentication.

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:

y para hosts:

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:

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.

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

Para visualizar un certificado de host:

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:

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:

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

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:

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

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:

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

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:

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

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

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:

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:

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:

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:

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

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:

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

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:

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

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

La utilidad sftp puede ser usada para abrir una sesión SFTP segura e interactiva. En su diseño, es similar a ftp excepto en que usa una conexión segura encriptada.

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

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

After you enter the correct password, you will be presented with a prompt. The sftp utility accepts a set of commands similar to those used by ftp (see A selection of available sftp commands).

For a complete list of available commands, see the sftp(1) manual page.

To open an X11 session over an SSH connection, use a command in the following form:

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

When an X program is run from the secure shell prompt, the SSH client and server create a new secure channel, and the X program data is sent over that channel to the client machine transparently.

Note that the X Window system must be installed on the remote system before X11 forwarding can take place. Enter the following command as root to install the X11 package group:

X11 forwarding can be very useful. For example, X11 forwarding can be used to create a secure, interactive session of the Print Settings utility. To do this, connect to the server using ssh and type:

The Print Settings tool will appear, allowing the remote user to safely configure printing on the remote system.

SSH can secure otherwise insecure TCP/IP protocols via port forwarding. When using this technique, the SSH server becomes an encrypted conduit to the SSH client.

Port forwarding works by mapping a local port on the client to a remote port on the server. SSH can map any port from the server to any port on the client. Port numbers do not need to match for this technique to work.

To create a TCP/IP port forwarding channel which listens for connections on the localhost, use a command in the following form:

For example, to check email on a server called mail.example.com using POP3 through an encrypted connection, use the following command:

Once the port forwarding channel is in place between the client machine and the mail server, direct a POP3 mail client to use port 1100 on the localhost to check for new email. Any requests sent to port 1100 on the client system will be directed securely to the mail.example.com server.

If mail.example.com is not running an SSH server, but another machine on the same network is, SSH can still be used to secure part of the connection. However, a slightly different command is necessary:

In this example, POP3 requests from port 1100 on the client machine are forwarded through the SSH connection on port 22 to the SSH server, other.example.com. Then, other.example.com connects to port 110 on mail.example.com to check for new email. Note that when using this technique, only the connection between the client system and other.example.com SSH server is secure.

Port forwarding can also be used to get information securely through network firewalls. If the firewall is configured to allow SSH traffic via its standard port (that is, port 22) but blocks access to other ports, a connection between two hosts using the blocked ports is still possible by redirecting their communication over an established SSH connection.