Red Hat Training

A Red Hat training course is available for RHEL 8

Capítulo 26. Asegurar las redes

26.1. Uso de comunicaciones seguras entre dos sistemas con OpenSSH

SSH (Secure Shell) es un protocolo que proporciona comunicaciones seguras entre dos sistemas utilizando una arquitectura cliente-servidor y permite a los usuarios iniciar la sesión en los sistemas anfitriones del servidor de forma remota. A diferencia de otros protocolos de comunicación remota, como FTP o Telnet, SSH cifra la sesión de inicio de sesión, lo que impide que los intrusos recojan las contraseñas no cifradas de la conexión.

Red Hat Enterprise Linux incluye los paquetes básicos OpenSSH: el paquete general openssh, el paquete openssh-server y el paquete openssh-clients. Tenga en cuenta que los paquetes OpenSSH requieren el paquete OpenSSL openssl-libs , que instala varias bibliotecas criptográficas importantes que permiten a OpenSSH proporcionar comunicaciones cifradas.

26.1.1. SSH y OpenSSH

SSH (Secure Shell) es un programa para entrar en una máquina remota y ejecutar comandos en esa máquina. El protocolo SSH proporciona comunicaciones seguras y encriptadas entre dos hosts no confiables a través de una red insegura. También puede reenviar conexiones X11 y puertos TCP/IP arbitrarios a través del canal seguro.

El protocolo SSH mitiga las amenazas de seguridad, como la interceptación de la comunicación entre dos sistemas y la suplantación de un determinado host, cuando se utiliza para el inicio de sesión de shell remoto o la copia de archivos. Esto se debe a que el cliente y el servidor SSH utilizan firmas digitales para verificar sus identidades. Además, toda la comunicación entre los sistemas cliente y servidor está cifrada.

OpenSSH es una implementación del protocolo SSH soportada por varios sistemas operativos Linux, UNIX y similares. Incluye los archivos centrales necesarios para el cliente y el servidor de OpenSSH. La suite OpenSSH consiste en las siguientes herramientas de espacio de usuario:

  • ssh es un programa de acceso remoto (cliente SSH)
  • sshd es un demonio SSH OpenSSH
  • scp es un programa de copia remota segura de archivos
  • sftp es un programa de transferencia segura de archivos
  • ssh-agent es un agente de autenticación para el almacenamiento de claves privadas
  • ssh-add añade identidades de clave privada a ssh-agent
  • ssh-keygen genera, gestiona y convierte las claves de autenticación para ssh
  • ssh-copy-id es un script que añade claves públicas locales al archivo authorized_keys en un servidor SSH remoto
  • ssh-keyscan - recoge las claves públicas de host SSH

Actualmente existen dos versiones de SSH: la versión 1 y la versión 2, más reciente. La suite OpenSSH en Red Hat Enterprise Linux 8 sólo soporta la versión 2 de SSH, que tiene un algoritmo de intercambio de claves mejorado que no es vulnerable a los exploits conocidos de la versión 1.

OpenSSH, como uno de los subsistemas criptográficos centrales de RHEL, utiliza políticas criptográficas para todo el sistema. Esto asegura que los conjuntos de cifrado y los algoritmos criptográficos débiles están desactivados en la configuración por defecto. Para ajustar la política, el administrador debe utilizar el comando update-crypto-policies para hacer la configuración más estricta o más floja o excluir manualmente las políticas criptográficas de todo el sistema.

El conjunto OpenSSH utiliza dos conjuntos diferentes de archivos de configuración: los de los programas cliente (es decir, ssh, scp, y sftp), y los del servidor (el demonio sshd ). La información de configuración de SSH para todo el sistema se almacena en el directorio /etc/ssh/. La información de configuración SSH específica del usuario se almacena en ~/.ssh/ en el directorio de inicio del usuario. Para una lista detallada de los archivos de configuración de OpenSSH, vea la sección FILES en la página man sshd(8).

Recursos adicionales

26.1.2. Configurar e iniciar un servidor OpenSSH

Utilice el siguiente procedimiento para una configuración básica que puede ser necesaria para su entorno y para iniciar un servidor OpenSSH. Tenga en cuenta que después de la instalación por defecto de RHEL, el demonio sshd ya está iniciado y las claves del servidor se crean automáticamente.

Requisitos previos

  • El paquete openssh-server está instalado.

Procedimiento

  1. Inicie el demonio sshd en la sesión actual y configúrelo para que se inicie automáticamente al arrancar: 

    # systemctl start sshd
# systemctl enable sshd

  2. Para especificar direcciones diferentes a las predeterminadas 0.0.0.0 (IPv4) o :: (IPv6) para la directiva ListenAddress en el archivo de configuración /etc/ssh/sshd_config y utilizar una configuración de red dinámica más lenta, añada la dependencia de la unidad de destino network-online.target al archivo de unidad sshd.service. Para ello, cree el archivo /etc/systemd/system/sshd.service.d/local.conf con el siguiente contenido: 

    [Unit]
Wants=network-online.target
After=network-online.target
  3. Revise si la configuración del servidor OpenSSH en el archivo de configuración /etc/ssh/sshd_config cumple con los requisitos de su escenario.

  4. Opcionalmente, cambie el mensaje de bienvenida que su servidor OpenSSH muestra antes de que un cliente se autentique editando el archivo /etc/issue, por ejemplo: 

    Welcome to ssh-server.example.com
Warning: By accessing this server, you agree to the referenced terms and conditions.

    Asegúrese de que la opción Banner no está comentada en /etc/ssh/sshd_config y su valor contiene /etc/issue: 

    # less /etc/ssh/sshd_config | grep Banner
Banner /etc/issue

    Tenga en cuenta que para cambiar el mensaje que se muestra después de un inicio de sesión exitoso tiene que editar el archivo /etc/motd en el servidor. Consulte la página man pam_motd para obtener más información.

  5. Vuelva a cargar la configuración de systemd y reinicie sshd para aplicar los cambios: 

    # systemctl daemon-reload
# systemctl restart sshd

Pasos de verificación

  1. Compruebe que el demonio sshd se está ejecutando: 

    # systemctl status sshd
● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2019-11-18 14:59:58 CET; 6min ago
     Docs: man:sshd(8)
           man:sshd_config(5)
 Main PID: 1149 (sshd)
    Tasks: 1 (limit: 11491)
   Memory: 1.9M
   CGroup: /system.slice/sshd.service
           └─1149 /usr/sbin/sshd -D -oCiphers=aes128-ctr,aes256-ctr,aes128-cbc,aes256-cbc -oMACs=hmac-sha2-256,>

Nov 18 14:59:58 ssh-server-example.com systemd[1]: Starting OpenSSH server daemon...
Nov 18 14:59:58 ssh-server-example.com sshd[1149]: Server listening on 0.0.0.0 port 22.
Nov 18 14:59:58 ssh-server-example.com sshd[1149]: Server listening on :: port 22.
Nov 18 14:59:58 ssh-server-example.com systemd[1]: Started OpenSSH server daemon.

  2. Conéctese al servidor SSH con un cliente SSH. 

    # ssh user@ssh-server-example.com
ECDSA key fingerprint is SHA256:dXbaS0RG/UzlTTku8GtXSz0S1++lPegSy31v3L/FAEc.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'ssh-server-example.com' (ECDSA) to the list of known hosts.

user@ssh-server-example.com's password:

Recursos adicionales

  • sshd(8) y sshd_config(5) páginas man

26.1.3. Uso de pares de claves en lugar de contraseñas para la autenticación SSH

Para mejorar aún más la seguridad del sistema, genere pares de claves SSH y luego aplique la autenticación basada en claves deshabilitando la autenticación por contraseña.

26.1.3.1. Configuración de un servidor OpenSSH para la autenticación basada en claves

Siga estos pasos para configurar su servidor OpenSSH para aplicar la autenticación basada en claves.

Requisitos previos

  • El paquete openssh-server está instalado.
  • El demonio sshd se está ejecutando en el servidor.

Procedimiento

  1. Abra la configuración de /etc/ssh/sshd_config en un editor de texto, por ejemplo: 

    # vi /etc/ssh/sshd_config

  2. Cambie la opción PasswordAuthentication por no: 

    PasswordAuthentication no

    En un sistema que no sea una instalación nueva por defecto, compruebe que no se ha configurado PubkeyAuthentication no y que la directiva ChallengeResponseAuthentication está establecida en no. Si está conectado de forma remota, sin utilizar la consola o el acceso fuera de banda, pruebe el proceso de inicio de sesión basado en la clave antes de desactivar la autenticación por contraseña.

  3. Para utilizar la autenticación basada en claves con los directorios personales montados en NFS, active el booleano use_nfs_home_dirs SELinux: 

    # setsebool -P use_nfs_home_dirs 1

  4. Vuelva a cargar el demonio sshd para aplicar los cambios: 

    # systemctl reload sshd

Recursos adicionales

  • sshd(8), sshd_config(5), y setsebool(8) páginas de manual

26.1.3.2. Generación de pares de claves SSH

Utilice este procedimiento para generar un par de claves SSH en un sistema local y para copiar la clave pública generada en un servidor OpenSSH. Si el servidor está configurado como corresponde, podrá iniciar sesión en el servidor OpenSSH sin necesidad de proporcionar ninguna contraseña.

Importante

Si completa los siguientes pasos como root, sólo root podrá utilizar las llaves.

Procedimiento

  1. Para generar un par de claves ECDSA para la versión 2 del protocolo SSH: 

    $ ssh-keygen -t ecdsa
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/joesec/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/joesec/.ssh/id_ecdsa.
Your public key has been saved in /home/joesec/.ssh/id_ecdsa.pub.
The key fingerprint is:
SHA256:Q/x+qms4j7PCQ0qFd09iZEFHA+SqwBKRNaU72oZfaCI joesec@localhost.example.com
The key's randomart image is:
+---[ECDSA 256]---+
|.oo..o=++        |
|.. o .oo .       |
|. .. o. o        |
|....o.+...       |
|o.oo.o +S .      |
|.=.+.   .o       |
|E.*+.  .  . .    |
|.=..+ +..  o     |
|  .  oo*+o.      |
+----[SHA256]-----+

    También puede generar un par de claves RSA utilizando la opción -t rsa con el comando ssh-keygen o un par de claves Ed25519 introduciendo el comando ssh-keygen -t ed25519.

  2. Para copiar la clave pública en una máquina remota: 

    $ ssh-copy-id joesec@ssh-server-example.com
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
joesec@ssh-server-example.com's password:
...
Number of key(s) added: 1

Now try logging into the machine, with: "ssh 'joesec@ssh-server-example.com'" and check to make sure that only the key(s) you wanted were added.

    Si no utiliza el programa ssh-agent en su sesión, el comando anterior copia la clave pública más recientemente modificada ~/.ssh/id*.pub si aún no está instalada. Para especificar otro archivo de clave pública o para dar prioridad a las claves en archivos sobre las claves almacenadas en la memoria por ssh-agent, utilice el comando ssh-copy-id con la opción -i.

Nota

Si reinstalas tu sistema y quieres conservar los pares de claves generados anteriormente, haz una copia de seguridad del directorio ~/.ssh/. Después de reinstalar, cópialo de nuevo en tu directorio principal. Puedes hacer esto para todos los usuarios de tu sistema, incluyendo root.

Pasos de verificación

  1. Inicie sesión en el servidor OpenSSH sin proporcionar ninguna contraseña: 

    $ ssh joesec@ssh-server-example.com
Welcome message.
...
Last login: Mon Nov 18 18:28:42 2019 from ::1

Recursos adicionales

  • ssh-keygen(1) y ssh-copy-id(1) páginas man

26.1.4. Uso de claves SSH almacenadas en una tarjeta inteligente

Red Hat Enterprise Linux 8 le permite utilizar claves RSA y ECDSA almacenadas en una tarjeta inteligente en clientes OpenSSH. Use este procedimiento para habilitar la autenticación usando una tarjeta inteligente en lugar de usar una contraseña.

Requisitos previos

  • En el lado del cliente, el paquete opensc está instalado y el servicio pcscd está funcionando.

Procedimiento

  1. Enumerar todas las claves proporcionadas por el módulo PKCS #11 de OpenSC incluyendo sus URIs PKCS #11 y guardar el resultado en el archivo keys.pub: 

    $ ssh-keygen -D pkcs11: > keys.pub
$ ssh-keygen -D pkcs11:
ssh-rsa AAAAB3NzaC1yc2E...KKZMzcQZzx pkcs11:id=%02;object=SIGN%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so
ecdsa-sha2-nistp256 AAA...J0hkYnnsM= pkcs11:id=%01;object=PIV%20AUTH%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so

  2. Para habilitar la autenticación mediante una tarjeta inteligente en un servidor remoto (example.com), transfiera la clave pública al servidor remoto. Utilice el comando ssh-copy-id con keys.pub creado en el paso anterior: 

    $ ssh-copy-id -f -i keys.pub username@example.com

  3. Para conectarse a example.com utilizando la clave ECDSA de la salida del comando ssh-keygen -D en el paso 1, puede utilizar sólo un subconjunto de la URI, que hace referencia a su clave de forma exclusiva, por ejemplo: 

    $ ssh -i "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so" example.com
Enter PIN for 'SSH key':
[example.com] $

  4. Puede utilizar la misma cadena URI en el archivo ~/.ssh/config para que la configuración sea permanente: 

    $ cat ~/.ssh/config
IdentityFile "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so"
$ ssh example.com
Enter PIN for 'SSH key':
[example.com] $

    Dado que OpenSSH utiliza el wrapper p11-kit-proxy y el módulo PKCS #11 de OpenSC está registrado en PKCS#11 Kit, puede simplificar los comandos anteriores: 

    $ ssh -i "pkcs11:id=%01" example.com
Enter PIN for 'SSH key':
[example.com] $

Si se omite la parte id= de un URI PKCS #11, OpenSSH carga todas las claves que están disponibles en el módulo proxy. Esto puede reducir la cantidad de escritura requerida: 

$ ssh -i pkcs11: example.com
Enter PIN for 'SSH key':
[example.com] $

Recursos adicionales

26.1.5. Cómo hacer que OpenSSH sea más seguro

Los siguientes consejos le ayudarán a aumentar la seguridad cuando utilice OpenSSH. Tenga en cuenta que los cambios en el archivo de configuración de /etc/ssh/sshd_config OpenSSH requieren la recarga del demonio sshd para que surtan efecto: 

# systemctl reload sshd
Importante

La mayoría de los cambios en la configuración del refuerzo de la seguridad reducen la compatibilidad con los clientes que no admiten algoritmos o conjuntos de cifrado actualizados.

Desactivación de los protocolos de conexión inseguros

  • Para que SSH sea realmente eficaz, hay que evitar el uso de protocolos de conexión inseguros que sean sustituidos por el conjunto OpenSSH. De lo contrario, la contraseña de un usuario podría estar protegida usando SSH para una sesión sólo para ser capturada más tarde cuando se conecte usando Telnet. Por esta razón, considere deshabilitar los protocolos inseguros, como telnet, rsh, rlogin y ftp.

Activación de la autenticación basada en clave y desactivación de la autenticación basada en contraseña

  • Desactivar las contraseñas para la autenticación y permitir sólo los pares de claves reduce la superficie de ataque y también podría ahorrar tiempo a los usuarios. En los clientes, genere pares de claves utilizando la herramienta ssh-keygen y utilice la utilidad ssh-copy-id para copiar las claves públicas de los clientes en el servidor OpenSSH. Para desactivar la autenticación basada en contraseña en su servidor OpenSSH, edite /etc/ssh/sshd_config y cambie la opción PasswordAuthentication por no: 

    PasswordAuthentication no

Tipos de claves

  • Aunque el comando ssh-keygen genera un par de claves RSA por defecto, puedes indicarle que genere claves ECDSA o Ed25519 utilizando la opción -t. El ECDSA (Algoritmo de Firma Digital de Curva Elíptica) ofrece un mejor rendimiento que el RSA con una fuerza de clave simétrica equivalente. También genera claves más cortas. El algoritmo de clave pública Ed25519 es una implementación de curvas de Edwards retorcidas que es más segura y también más rápida que RSA, DSA y ECDSA.

    OpenSSH crea automáticamente las claves de host del servidor RSA, ECDSA y Ed25519 si no las tiene. Para configurar la creación de claves de host en RHEL 8, utilice el servicio instanciado sshd-keygen@.service. Por ejemplo, para desactivar la creación automática del tipo de clave RSA: 

    # systemctl mask sshd-keygen@rsa.service
  • Para excluir determinados tipos de claves para las conexiones SSH, comente las líneas correspondientes en /etc/ssh/sshd_config y vuelva a cargar el servicio sshd. Por ejemplo, para permitir sólo las claves de host Ed25519: 
# HostKey /etc/ssh/ssh_host_rsa_key
# HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Puerto no predeterminado

  • Por defecto, el demonio sshd escucha en el puerto TCP 22. Cambiar el puerto reduce la exposición del sistema a ataques basados en el escaneo automático de la red y, por tanto, aumenta la seguridad a través de la oscuridad. Puede especificar el puerto utilizando la directiva Port en el archivo de configuración /etc/ssh/sshd_config.

    También tienes que actualizar la política de SELinux por defecto para permitir el uso de un puerto no predeterminado. Para ello, utilice la herramienta semanage del paquete policycoreutils-python-utils: 

    # semanage port -a -t ssh_port_t -p tcp port_number

    Además, actualice la configuración de firewalld: 

    # firewall-cmd --add-port port_number/tcp
# firewall-cmd --runtime-to-permanent

    En los comandos anteriores, sustituya port_number por el nuevo número de puerto especificado mediante la directiva Port.

No hay acceso a la raíz

  • Si su caso de uso particular no requiere la posibilidad de iniciar sesión como usuario root, debería considerar establecer la directiva de configuración PermitRootLogin a no en el archivo /etc/ssh/sshd_config. Al deshabilitar la posibilidad de iniciar sesión como usuario root, el administrador puede auditar qué usuarios ejecutan qué comandos privilegiados después de iniciar sesión como usuarios normales y luego obtener derechos de root.

    Como alternativa, configure PermitRootLogin en prohibit-password: 

    PermitRootLogin prohibir-contraseña

    Esto refuerza el uso de la autenticación basada en claves en lugar del uso de contraseñas para iniciar la sesión como root y reduce los riesgos al evitar los ataques de fuerza bruta.

Uso de la extensión X Security

  • El servidor X en los clientes de Red Hat Enterprise Linux no proporciona la extensión X Security. Por lo tanto, los clientes no pueden solicitar otra capa de seguridad cuando se conectan a servidores SSH no confiables con el reenvío X11. La mayoría de las aplicaciones no pueden ejecutarse con esta extensión habilitada de todos modos.

    Por defecto, la opción ForwardX11Trusted en el archivo /etc/ssh/ssh_config.d/05-redhat.conf se establece en yes, y no hay diferencia entre el comando ssh -X remote_machine (host no confiable) y ssh -Y remote_machine (host confiable).

    Si su escenario no requiere la función de reenvío de X11 en absoluto, establezca la directiva X11Forwarding en el archivo de configuración /etc/ssh/sshd_config a no.

Restringir el acceso a usuarios, grupos o dominios específicos

  • Las directivas AllowUsers y AllowGroups en el archivo de configuración del servidor /etc/ssh/sshd_config le permiten permitir sólo a ciertos usuarios, dominios o grupos conectarse a su servidor OpenSSH. Puede combinar AllowUsers y AllowGroups para restringir el acceso con mayor precisión, por ejemplo: 

    AllowUsers *@192.168.1.*,*@10.0.0.*,!*@192.168.1.2
AllowGroups example-group

    Las líneas de configuración anteriores aceptan conexiones de todos los usuarios de los sistemas de las subredes 192.168.1.* y 10.0.0.*, excepto del sistema con la dirección 192.168.1.2. Todos los usuarios deben estar en el grupo example-group. El servidor OpenSSH rechaza todas las demás conexiones.

    Tenga en cuenta que el uso de listas de permitidos (directivas que empiezan por Allow) es más seguro que el uso de listas de bloqueados (opciones que empiezan por Deny) porque las listas de permitidos bloquean también a nuevos usuarios o grupos no autorizados.

Cambiar las políticas criptográficas de todo el sistema

  • OpenSSH utiliza las políticas criptográficas de todo el sistema RHEL, y el nivel de política criptográfica por defecto de todo el sistema ofrece una configuración segura para los modelos de amenazas actuales. Para que la configuración criptográfica sea más estricta, cambie el nivel de política actual: 

    # update-crypto-policies --set FUTURE
Setting system policy to FUTURE
  • Para optar por las políticas de criptografía de todo el sistema para su servidor OpenSSH, descomente la línea con la variable CRYPTO_POLICY= en el archivo /etc/sysconfig/sshd. Después de este cambio, los valores que especifique en las secciones Ciphers, MACs, KexAlgoritms, y GSSAPIKexAlgorithms en el archivo /etc/ssh/sshd_config no serán anulados. Tenga en cuenta que esta tarea requiere una gran experiencia en la configuración de opciones criptográficas.
  • Consulte Uso de políticas criptográficas en todo el sistema en el título de endurecimiento de la seguridad de RHEL 8 para obtener más información.

Recursos adicionales

  • sshd_config(5), ssh-keygen(1), crypto-policies(7), y update-crypto-policies(8) páginas de manual

26.1.6. Conectarse a un servidor remoto utilizando un host de salto SSH

Utilice este procedimiento para conectarse a un servidor remoto a través de un servidor intermediario, también llamado host de salto.

Requisitos previos

  • Un host de salto acepta conexiones SSH desde su sistema.
  • Un servidor remoto acepta conexiones SSH sólo desde el host de salto.

Procedimiento

  1. Defina el host de salto editando el archivo ~/.ssh/config, por ejemplo: 

    Host jump-server1
  HostName jump1.example.com

  2. Añada la configuración de salto del servidor remoto con la directiva ProxyJump a ~/.ssh/config, por ejemplo: 

    Host remote-server
  HostName remote1.example.com
  ProxyJump jump-server1

  3. Conectar con el servidor remoto a través del servidor de salto: 

    $ ssh remote-server

    El comando anterior es equivalente al comando ssh -J jump-server1 remote-server si se omiten los pasos de configuración 1 y 2.

Nota

Puede especificar más servidores de salto y también puede omitir la adición de definiciones de host al archivo de configuraciones cuando proporciona sus nombres de host completos, por ejemplo: 

$ ssh -J jump1.example.com,jump2.example.com,jump3.example.com remote1.example.com

Cambie la notación de sólo nombre de host en el comando anterior si los nombres de usuario o los puertos SSH en los servidores de salto difieren de los nombres y puertos en el servidor remoto, por ejemplo: 

$ ssh -J johndoe@jump1.example.com:75,johndoe@jump2.example.com:75,johndoe@jump3.example.com:75 joesec@remote1.example.com:220

Recursos adicionales

  • ssh_config(5) y ssh(1) páginas man

26.1.7. Conexión a máquinas remotas con claves SSH usando ssh-agent

Para evitar la introducción de una frase de contraseña cada vez que inicie una conexión SSH, puede utilizar la utilidad ssh-agent para almacenar en caché la clave privada SSH. La clave privada y la frase de contraseña permanecen seguras.

Requisitos previos

  • Tienes un host remoto con el demonio SSH en ejecución y accesible a través de la red.
  • Conoce la dirección IP o el nombre de host y las credenciales para iniciar sesión en el host remoto.
  • Ha generado un par de claves SSH con una frase de paso y ha transferido la clave pública a la máquina remota. Para más información, consulte Generación de pares de claves SSH.

Procedimiento

  1. Opcional: Compruebe que puede utilizar la clave para autenticarse en el host remoto:

    1. Conéctese al host remoto mediante SSH: 

      $ ssh example.user1@198.51.100.1 hostname

    2. Introduzca la frase de contraseña que estableció al crear la clave para dar acceso a la clave privada. 

      $ ssh example.user1@198.51.100.1 hostname
 host.example.com

  2. Inicie el ssh-agent. 

    $ eval $(ssh-agent)
Agent pid 20062

  3. Añade la clave a ssh-agent. 

    $ ssh-add ~/.ssh/id_rsa
Enter passphrase for ~/.ssh/id_rsa:
Identity added: ~/.ssh/id_rsa (example.user0@198.51.100.12)

Pasos de verificación

  • Opcional: Inicie sesión en el equipo anfitrión mediante SSH. 

    $ ssh example.user1@198.51.100.1

Last login: Mon Sep 14 12:56:37 2020

    Tenga en cuenta que no ha tenido que introducir la frase de contraseña.

26.1.8. Recursos adicionales

Para obtener más información sobre la configuración y la conexión a los servidores y clientes de OpenSSH en Red Hat Enterprise Linux, consulte los recursos enumerados a continuación.

Documentación instalada

  • sshd(8) La página de manual documenta las opciones disponibles en la línea de comandos y proporciona una lista completa de los archivos y directorios de configuración compatibles.
  • la página de manualssh(1) proporciona una lista completa de las opciones disponibles en la línea de comandos y de los archivos y directorios de configuración admitidos.
  • la página de manualscp(1) proporciona una descripción más detallada de la utilidad scp y su uso.
  • la página de manualsftp(1) proporciona una descripción más detallada de la utilidad sftp y su uso.
  • la página manssh-keygen(1) documenta en detalle el uso de la utilidad ssh-keygen para generar, gestionar y convertir las claves de autenticación utilizadas por ssh.
  • la página de manualssh-copy-id(1) describe el uso del script ssh-copy-id.
  • ssh_config(5) La página de manual documenta las opciones de configuración del cliente SSH disponibles.
  • la página de manualsshd_config(5) proporciona una descripción completa de las opciones de configuración disponibles del demonio SSH.
  • la página de manualupdate-crypto-policies(8) proporciona orientación sobre la gestión de políticas criptográficas en todo el sistema
  • la página de manualcrypto-policies(7) proporciona una visión general de los niveles de política criptográfica de todo el sistema

Documentación en línea