Logo OpenSSH
22 Abr 2017

Instalar y configurar el servicio SSH en Debian

por | publicado en: Criptografía, Debian, Linux, Seguridad, Servicios de Red, SSH, Ubuntu | 2
 
 

Índice General

  1. ¿Qué es SSH y para que sirve?
  2. Instalación del servidor y del cliente
  3. Configuración del servidor
  4. Reiniciar el servidor
  5. Consideración a tener en cuenta si deshabilitamos el acceso con RSA

Enlaces relacionados con el artículo en ZeppelinuX
Enlaces externos
 

  1. ¿Qué es SSH y para que sirve? (Volver al índice General)
    SSH (Secure SHell) es un conjunto de estándares y protocolo de red que permite establecer una comunicación a través de un canal seguro entre un cliente local y un servidor remoto. Utiliza una llave pública para autenticar el servidor remoto y, de manera opcional, permitir al servidor remoto autenticar al usuario. SSH provee confidencialidad e integridad en la transferencia de los datos utilizando criptografía y MAC (Message Authentication Codes o Códigos de Autenticación de Mensaje).

    SSH nos permite acceder a la interfaz de línea de comandos (CLI) de la máquina remota, redirigir el tráfico del sistema de ventanas X, si se está ejecutando un servidor X en el equipo remoto y transferir archivos (subir o descargar) entre el cliente y el servidor, todo ello, a través de un canal cifrado, que evita que terceros puedan ver en claro el nombre de usuario y contraseña utilizados en el establecimiento de la conexión, y tampoco los datos que se transmitan por ese canal cifrado.

    SFTP (SSH File Transfer Protocol) es un protocolo que provee la funcionalidad de transferencia y manipulación de archivos a través de una conexión cifrada con SSH.

    SCP (Secure Copy o Copia Segura) es un protocolo seguro para transferir archivos a través de SSH. SCP sólo implementa la transferencia de archivos, pues la autenticación requerida es realizada a través de SSH.

    SSH se basa en la artquitectura cliente/servidor. Trabaja en la capa de aplicación y como protocolo de transporte utiliza TCP. El puerto estándar por el que escucha es el 22/TCP.

    En este artículo mostraremos como instalar OpenSSH (Open Secure Shell), tanto el cliente SSH como el servidor SSH, para realizar comunicaciones cifradas utilizando el protocolo SSH.

    El paquete openssh-server proporciona el demonio sshd que permite a los clientes ssh y scp establecer conexiones seguras, y sftp-server que permite a los clientes sftp transferir archivos, también de forma segura.

    El paquete openssh-client proporciona los clientes de ssh, scp y sftp, los programas ssh-agent y ssh-add para hacer más comoda la autenticación de clave pública, y las utilidades ssh-keygen, ssh-keyscan, ssh-copy-id y ssh-argv0.

    OpenSSH es una alternativa de código fuente abierto, con licencia BSD. OpenSSH es un proyecto creado por el equipo de desarrollo de OpenBSD. Se considera más seguro que la versión privativa de Tatu Ylönen, gracias a la constante auditoría que se realiza sobre el código fuente por parte de una enorme comunidad de desarrolladores. Es la ventaja que brinda el Software Libre.

    OpenSSH incluye servicio y clientes para los protocolos SSH, SFTP y SCP.

    2.  

  2. Instalación del servidor y del cliente (Volver al índice General)
    Antes de comenzar la instalación actualizamos los repositorios con la siguiente orden:

    $ sudo apt-get update

    A continuación procedemos a la instalación de los paquetes correspondientes al servidor (openssh-server) y al cliente (openssh-client).

    $ sudo apt-get install openssh-server openssh-client

    • Comprobar que el servidor SSH está iniciado (Volver al índice General)
      Para comprobar que el servidor SSH esta iniciado ejecutaremos la siguiente orden:

      $ sudo ps -ef | grep ssh
[sudo] password for karfer: 
root       4449      1  0 21:13 ?        00:00:00 /usr/sbin/sshd -D
karfer     6039   6005  0 21:24 ?        00:00:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session x-session-manager

    • Comprobar que el servidor SSH está escuchando por el puerto TCP 22 (Volver al índice General)
      Para comprobar que el servidor SSH está escuchando por el puerto TCP 22 ejecutaremos la siguiente orden:

      $ sudo netstat -ltn | grep :22
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN

      Como podemos ver en la salida del comando, en servicio está a la escucha por el puerto 22 tanto para IPv4 como para IPv6.


    3.  
     

  3. Configuración del servidor (Volver al índice General)
     
    Archivos de configuración:

    • /etc/ssh/sshd_config: Archivo principal de configuración del servidor SSH.
    • /etc/ssh/ssh_config: Archivo principal de configuración de los clientes SSH.
    • ~/.ssh/config: Archivo personal de cada usuario. Contiene la configuración utilizada por los clientes SSH. Permite al usuario local utilizar una configuración distinta a la definida en el archivo /etc/ssh/ssh_config.
    • ~/.ssh/known_hosts: Archivo personal de cada usuario. Contiene las firmas digitales de los servidores SSH a los que se conectan los clientes. Cuando éstas firmas cambian, se pueden actualizar ejecutando el comando ssh-keygen -R, pasando el nombre del anfitrión o la IP del anfitrión como argumento. Este comando elimina la entrada correspondiente en el archivo ~/.ssh/known_hosts y, permite añadir de nuevo al anfitrión con una nueva firma digital. La sintaxis genérica sería:
       

      $ ssh-keygen -R nombre_o_ip_del_servidor_SSH
    • ~/.ssh/authorized_keys: Archivo personal para cada usuario. Contiene los certificados de los clientes SSH, para permitir autenticación hacia servidores SSH sin requerir contraseña.

     
    Tras la instalación procederemos a la configuración del servidor, para ello, editaremos el fichero de configuración /etc/ssh/sshd_config.

    NOTA: es importante hacer copia de seguridad del archivo /etc/ssh/sshd_config antes de realizar cualquier cambio.

    $ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

    En nuestro ejemplo, editaremos el archivo /etc/ssh/sshd_config con el editor de texto plano nano, presente en casi todas las distribuciones Linux:

    $ sudo nano /etc/ssh/sshd_config

    Sobre el fichero de configuración por defecto, modificaremos las directrices establecidas en él y añadiremos aquellas directrices que no estén.
    A continuación mostraremos las directrices más importantes a tener en cuenta a la hora de configurar el servidor:

    • Directriz Port (Volver al índice General)
      De forma predeterminada, el servicio SSH escucha por el puerto 22. La directriz por defecto sería:

      Port 22

      Una forma de elevar la seguridad del servidor SSH, consiste en cambiar el número de puerto predeterminado por otro que sólo el administrador del sistema conozca. A este tipo de técnicas se les conoce como seguridad por oscuridad.
      Los atacantes buscarán servidores que estén escuchando por el puerto 22. Cambiar de puerto disminuye considerablemente la posibilidad de una intrusión. Podemos cambiarlo a otro puerto, preferiblemente entre el 1024 y 65535. En nuestro ejemplo, configuraremos el servidor para que escuche por el puerto 54312:

      Port 54312

      Si trabajamos tras un encaminador/NATP y no queremos cambiar el puerto estándar del servidor SSH, podemos filtrar el puerto 22 en el encaminador/NATP prohibiendo todas las conexiones entrantes al puerto 22 y por otro lado, redirigir las conexiones entrantes al puerto 54312 del encaminador/NATP al puerto 22 del servidor SSH.

    • Directriz ListenAddress (Volver al índice General)
      De forma predeterminada, el servicio SSH escuchará peticiones a través de todas las direcciones IP correspondientes a todas las interfaces de red del sistema. La directriz por defecto sería:

      ListenAddress 0.0.0.0

      En nuestro ejemplo, configuraremos el servidor para que escuche por la interfaz de red con IP 192.168.0.55, a la cual sólo se puede acceder desde la red local:

      ListenAddress 192.168.0.55

      Al día de la fecha que se escribe este artículo, con la versión OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016, esta opción falla. Al reiniciar el equipo, el servicio se ejecuta pero no escucha por ningún puerto. Estoy a la espera que parcheen la versión. Por lo tanto si ves que tu demonio se lanza pero no escucha por ningún puerto, puede ser debido a la configuración de esta directriz. Para corregir el fallo no queda más remedio que establecer la directriz al valor por defecto:

      ListenAddress 0.0.0.0

    • Directriz Protocol (Volver al índice General)
      Existen dos versiones de SSH en cuanto a su protocolo de comunicación, SSHv1 y SSHv2. SSHv1 esta en desuso pero todavía se incluye por compatibilidad. SSHv1 tiene varias vulnerabilidades conocidas, una de ellas en concreto, es un agujero de seguridad que potencialmente permite a un intruso insertar datos en la corriente de comunicación, por lo que su uso ya no es recomendable. Un error frecuente es dejar que el demonio SSH permita el uso de las dos versiones. Para evitar el uso de la versión SSHv1 y los posibles ataques a esta, basta con indicar en esta directriz que solo admita comunicaciones de SSH basadas en el protocolo SSHv2, el cual tiene un algoritmo de intercambio de claves mejorado y que no es vulnerable a los agujeros de seguridad de la versión SSHv1.

      Protocol 2

    • Directriz LoginGraceTime (Volver al índice General)
      En esta directriz se establece el tiempo, en segundos, durante el cual la pantalla de login estará disponible para que el usuario introduzca su nombre de usuario y contraseña, si no lo hace durante ese período de tiempo el login se cerrará, evitando así dejar por tiempo indeterminado pantallas de login sin que nadie las use, o que alguien este intentando mediante un script adivinar un usuario y su contraseña. Si el valor es 0, no hay límite de tiempo para que un usuario se autentique, lo cual no es recomendable ya que de esta forma un atacante podría utilizar ataques de fuerza bruta o usando métodos de diccionario para adivinar la contraseña, por lo tanto no es recomendable dejar esta directriz a 0. En nuestro ejemplo lo estableceremos en 40 segundos.

      LoginGraceTime 40

    • Directriz PermitRootLogin (Volver al índice General)
      Probablemente sea la directriz de seguridad más importante que podemos establecer para asegurar nuestro servidor SSH. En los sistemas Unix y Linux se crea por defecto al usuario root, lo que implica que ya conocemos la existencia de al menos un usuario, ¡y que usuario!, con privilegios de adnimistrador. Muchos ataques de fuerza bruta se concentran en atacar al usuario root con la esperanza de que tenga una contraseña débil.
      Sabiendo una parte de la ecuación (root) solo será cuestión de tiempo para que alguien con paciencia y suerte vulnere el sistema. En esta directriz denegamos el acceso al usuario root y por lo tanto, cualquier intento de ataque directo al usuario root será inútil.
      Al denegar el acceso al usuario root, cada vez que necesitemos realizar tareas administrativas, accederemos como un usuario normal y una vez dentro, utilizando alguno de los comandos su o sudo podremos realizar dichas tareas administrativas. Por lo tanto, denegando el acceso al usuario root, el atacante tendrá que acertar tanto el nombre de un usuario del sistema como su contraseña, algo que disminuye notablemente la probabilidad de una intrusión.

      PermitRootLogin no

    • Directriz StrictModes (Volver al índice General)
      En esta directriz se establece que sshd revisara los modos y permisos de los archivos de los usuarios y el directorio $HOME de el usuario antes de aceptar la sesión. Esto es normalmente deseable porque a veces algunos usuarios dejan sus directorios, accidentalmente, con permiso de escritura para cualquiera. El valor predeterminado es yes, por lo tanto, lo dejaremos con su valor predeterminado.

      StrictModes yes

    • Directriz MaxAuthTries (Volver al índice General)
      El valor de esta directriz establece el máximo número de intentos de autenticación permitidos por conexión, es decir, la cantidad de veces que podemos equivocarnos al ingresar el usuario y/o contraseña. Una vez que los intentos alcanzan la mitad de este valor, las conexiones fallidas siguientes serán registradas. Después del máximo número de intentos se cerrará la conexión. Es posible volver a intentarlo, pero el límite de intentos por vez evita ataques basados en la persistencia de la conexión.

      MaxAuthTries 5

    • Directriz MaxStartups (Volver al índice General)
      El valor de esta directriz establece el máximo número de conexiones simultaneas de login que permitirá el servidor SSH por cada IP que intente conectarse. Hay ataques muy efectivos que dividen el ataque en una gran cantidad de conexiones de login. Es decir, el atacante divide en una gran cantidad de logins los intentos por ingresar, aumentando sus posibilidades de adivinar antes al usuario y su contraseña.

      MaxStartups 5

      También podemos utilizar la siguiente sintáxis:

      MaxStartups 10:30:60

      Donde:
      10: Número de conexiones no autenticadas antes de comenzar a caer.
      30: Porcentaje de probabilidad de caer una vez que llegamos a 10.
      60: Número máximo de conexiones en las que comenzamos a caer.

    • Directrices para autenticar con password (Volver al índice General)
      La directriz PasswordAuthentication habilita o deshabilita la autenticación con contraseñas. Por defecto está permitida la autenticación con contraseña. Si establecemos el valor no sólo se permitirá el acceso a través de firmas digitales. Es muy importante no cambiar el valor de esta directriz a no hasta haber instalado nuestra firma digital.

      PasswordAuthentication yes

      La directriz PermitEmptyPasswords especifica si se permite el uso de contraseñas vacías, es decir, autenticarse sin contraseña (no recomendable por motivos de seguridad). Esta directriz es válida cuando se usa conjuntamente con PasswordAuthenticacion yes.

      PermitEmptyPasswords no

    • Directrices para permitir el uso de X11 (Volver al índice General)
      La directriz X11Forwarding establece si se permitirá la ejecución remota de aplicaciones gráficas que utilicen el servidor X11. Es necesario que el valor esté establecido a yes para poder ejecutar aplicaciones gráficas.

      X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

    • Directriz AllowUsers (Volver al índice General)
      Con esta directriz establecemos que usuarios del sistema pueden ingresar vía SSH. Solo los usuarios listados en esta directriz podrán acceder.

      AllowUsers mortadelo filemon anacleto sacarino

      Los usuarios mortadelo, filemon y anacleto podrán acceder desde cualquier ordenador, no se valida el host desde el que se conectan. Si se quiere más seguridad, es posible indicar también el host o hosts (desde los cuales el usuario se puede conectar) mediante el símbolo @. Veamos los siguientes ejemplos:

      AllowUsers mortadelo@192.168.0.2          (Solo desde la IP indicada)
AllowUsers mortadelo@10.33.0.*            (Toda la red indicada)
AllowUsers mortadelo@*.zeppelinux.es      (Todo el dominio indicado)
AllowUsers mortadelo@ventas.zeppelinux.es (Solo el equipo del dominio indicado)

      Combinación de varias:

      AllowUsers mortadelo@192.168.1.2 filemon@10.33. 0.* anacleto@*.zeppelinux.es sacarino

    • Directriz UseDNS (Volver al índice General)
      Cuando un cliente SSH realiza una conexión hacia un servidor SSH, el servidor intentará resolver la dirección IP del cliente. Si el servidor DNS predeterminado del sistema carece de una zona de resolución inversa que resuelva un nombre para la dirección IP del cliente, la conexión se demorará algunos segundos más de lo normal. Podemos deshabilitar esta directriz para agilizar las conexiones SSH en redes donde, se carece de servidores DNS que tengan zonas de reenvío para resolver los nombres o zonas de resolución inversa para resolver las direcciones IP de los segmentos de red local. En nuestro ejemplo lo dejaremos desactivado.

      UseDNS no

    • Directriz HostKey (Volver al índice General)
      Estudiemos las siguientes líneas:

      # HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
# HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key

      La directriz HostKey nos indica la ubicación de las llaves públicas para el servidor sshd, tanto para el protocolo SSHv1 y SSHv2 de SSH. Como en nuestro ejemplo solo usaremos el protocolo SSHv2, eliminaremos (o comentaremos) las líneas correspondientes al protocolo SSHv1, y si sólo queremos utilizar el algorítmo DSA, más seguro que RSA, también podremos eliminar (o comentar) la línea que hace referencia a RSA, de tal manera que quedará así:

      # HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key

    • Directriz PrintMotd (Volver al índice General)
      Esta directriz establece si se presentará o no el mensaje del día (MOTD). El motd de Linux es un archivo que contiene un mensaje del día que se muestra a todos los usuarios que se conectan a la máquina por terminal. Normalmente se usa para informar a los usuarios sobre el estado del servidor o simplemente para dar la bienvenida a la máquina. La ruta al archivo es /etc/mtod. Se trata de un archivo de texto plano el cual podemos personalizar. Hay que tener en cuenta que si el motd ya está habilitado para los usuarios del sistema, si lo habilitamos en /etc/ssh/sshd_config, al iniciar sesión en el servidor SSH, este aparecerá duplicado. El motd se muestra después de autenticarnos en el servidor.

      PrintMotd no

    • Directriz Banner (Volver al índice General)
      Por medio de esta directriz podemos presentar un banner de acceso que nos permitirá mostrar un mensaje antes de la autenticación. Enseñar un cartel de advertencia exponiendo temas legales de un acceso no autorizado.
      El banner de acceso no es más que el contenido de un fichero de texto plano ubicado en algún sitio del sistema y que podremos personalizar a nuestro gusto. El banner de acceso se presenta antes de autenticarnos en el servidor.

      Banner /etc/ssh/ssh_pre-login


      •  
       

    • Directries de registro de eventos (Volver al índice General)
      El registro de eventos del servicio es importante así como la ruta donde guardarlos, un atacante experimentado intentará limpiar los logs para evitar ser atrapado.
      En estas directrices se especifican los parámetros para el registro de eventos:

      • SyslogFacility especifica el tipo de registros que generará, en este caso es AUTH, es decir, de las autenticaciones que se hacen contra el servidor. El parámetro AUTH es el predeterminado.
      • LogLevel con el valor INFO es el valor predeterminado. Otros parámetros están especificados en la página del manual de sshd_config (mansshd_config), los parámetros DEBUG2 y DEBUG3 cada uno de ellos especifican el nivel más alto de registro. Guardar registros con el nivel DEBUG viola la privacidad de los usuarios y por lo tanto no es recomendable.

      En nuestro ejemplo el registro de eventos quedaría configurado de la siguiente manera:

      SyslogFacility AUTH
LogLevel INFO

    • Directriz RSAAuthentication (Volver al índice General)
      Con esta directriz deshabilitamos la autenticación con RSA.

      RSAAuthentication no

    • Directriz PubkeyAuthentication (Volver al índice General)
      Esta directriz especifica el uso de autenticación por medio de la llave pública. En nuestro caso lo habilitaremos.

      PubkeyAuthentication yes

    • Directriz AuthorizedKeysFile (Volver al índice General)
      Esta directriz se usa en conjunto cuando se usa autenticación por llave pública, y especifica donde se guardaran las llaves en el host remoto. El valor por defecto es ~/.ssh/authorized_keys esta ruta es por defecto para el protocolo SSHv2 de SSH.

      AuthorizedKeysFile %h/.ssh/authorized_keys

    • Directriz IgnoreUserKnownHosts (Volver al índice General)
      Esta directriz especifica si se ignorara o no el uso de el archivo ~/.ssh/known_hosts en el cual se agregan las llaves de los servidores SSH a los cuales nos conectamos y confiamos. Por lo tanto debe de estar en no para no ignorar este archivo.

      IgnoreUserKnownHosts no

    • Directriz AllowTcpForwarding (Volver al índice General)
      Especifica si se permite hacer redireccionamiento de protocolos basados en TCP. Permite crear túneles a conexiones de protocolos no seguros, enviando la información en texto plano por un túnel cifrado. Muy usada en conexiones POP3 o IMAP, se recomienda dejarlo por defecto.

      AllowTcpForwarding yes

    • Directriz PrintLastLog (Volver al índice General)
      Aquí se especifica si se mostrara un mensaje mostrando la dirección IP de donde se conecto el usuario la ultima vez. Muy útil para saber si alguien más se está conectando con un usuario en especifico.

      PrintLastLog yes

    • Directriz TCPKeepAlive (Volver al índice General)
      Nos indica que el servidor sshd enviará mensajes de keepalive al cliente después de que detecta alguna inactividad. Este método puede ser explotado por técnicas de spoofing.

      TCPKeepAlive yes

    • Directriz UsePrivilegeSeparation (Volver al índice General)
      Significa que después de que la sesión SSH se ha establecido se pasaran los privilegios de ese proceso al usuario de quien inicie la conexión, si se deshabilita, el proceso estará a nombre de root. Muy importante para evitar elevación de privilegios.

      UsePrivilegeSeparation yes

    • Directriz ClientAliveInterval (Volver al índice General)
      Esta directriz especifica el intervalo de tiempo en segundos en el cual después de que no se ha recibido ningún dato de el cliente, sshd enviara un mensaje a través del canal cifrado para requerir una respuesta de el cliente, el valor predeterminado es 0, el cual significa que no se envía tal mensaje. Esta opción sólo se aplica al protocolo SSHv2. Es útil cuando se tiene una conexión intermitente y se requiere que la sesión esté abierta sin que se cierre la sesión.

      ClientAliveInterval 0

    • Directriz ClientAliveCountMax (Volver al índice General)
      Nos indica las veces que el servidor sshd enviará mensajes keepalive cuando el cliente está inactivo. Si el cliente no envía ninguna respuesta, entonces el servidor terminara la conexión y por lo tanto la sesión. Si tenemos conexiones intermitentes es recomendable subir el numero a este valor. Hay que tener en cuenta que esta opción es diferente a la opción TCPKeepAlive, estos mensajes son enviados a través de el canal cifrado, por lo tanto no puede ser explotado por técnicas de spoofing como el TCPKeepAlive.

      ClientAliveCountMax 3

    • Directriz PidFile (Volver al índice General)
      Esta opcion establece el nombre y ruta del archivo donde se guarda el identificador de proceso (pid) de sshd.

      PidFile /var/run/sshd.pid

    • Directriz Subsystem (Volver al índice General)
      Esta opción lo que hace es iniciar el servidor sftp-server el cual es un sustituto para un servidor FTP, pero la comunicación es segura, ya que se hace por un canal cifrado.

      Subsystem sftp /usr/libexec/sftp-server

    • Directriz PermitBlacklistedKeys (Volver al índice General)
      Si esta directriz se establece a yes permitirá hacer login con claves en lista negra.

      PermitBlacklistedKeys no

    • Directriz IgnoreRhosts y RhostsRSAAuthentication (Volver al índice General)
      Con estas directrices denegamos el uso de relaciones de confianza establecidas en los ficheros ~/.rhosts y ~/.shosts de los usuarios:

      IgnoreRhosts yes
RhostsRSAAuthentication no

    • Directriz HostbasedAuthentication (Volver al índice General)
      Deshabilitar autenticación basada en host.

      HostbasedAuthentication no

    • Directriz UsePAM (Volver al índice General)
      Si usamos claves no necesitamos PAM (Módulos de autenticación Conectables) y permitimos a sshd funcionar como un usuario no root.

      UsePAM no
  4. Reiniciar el servidor (Volver al índice General)
    Tras realizar cambios en el archivo /etc/ssh/sshd_config tendremos que reiniciar el servicio para que los cambios surtan efecto. Para ello, ejecutaremos el siguiente comando:

    $ sudo service sshd restart

    o también:

    $ sudo /etc/init.d/ssh restart

    o si utilizamos Systemd:

    $ sudo systemctl restart ssh
  5. Consideración a tener en cuenta si deshabilitamos el acceso con RSA (Volver al índice General)
    Si optamos por deshabilitar en el servidor SSH el algoritmo de cifrado RSA, en favor del algoritmo DSA, en el equipo cliente, antes de intentar conectarnos al servidor SSH remoto, debemos de:

    • Borrar el archivo ~/.ssh/known_hosts el cual mantiene el fingerprint del servidor generado con RSA y que se genere uno nuevo cuando realicemos la conexión. 
      usuario@cliente:~$ rm -rf .ssh/known_hosts
    • O también utilizar esta otra forma más elegante, que explicamos en el apartado de Archivos de configuración, la cual nos permite actualizar los fingerprint guardados. Este comando elimina la entrada correspondiente en el archivo ~/.ssh/known_hosts, permitiendo añadir de nuevo al anfitrión con una nueva firma digital.
       

      $ ssh-keygen -R nombre_o_ip_del_servidor_SSH

 
Enlaces relacionados con el artículo en ZeppelinuX (Volver al índice General)

 
Enlaces externos (Volver al índice General)

Espero que este artículo os haya sido de utilidad. Si pensáis que podéis colaborar para mejorar este artículo, que hay algo erróneo en él o simplemente deseáis comentarlo, por favor, dejad vuestra opinión más abajo.
 
Seguir J. Carlos:

Técnico Informático - Desarrollo Web - Administración de Redes

Técnico Informático. Desarrollo Web. Administración de redes.

Últimas publicaciones de

2 comentarios

  1. Vicente
    | Reply

    BUENISIMO
    Se echan en falta mas tutoriales como este y menos vide-tutoriales.
    Le falta una actualización… pero es muy completo y muy bien explicado
    Muchísimas gracias

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.