110.3 Lección 1
Versión: |
5.0 |
---|---|
Tema: |
110 Seguridad |
Objetivo: |
110.3 Protección de datos mediante cifrado |
Lección: |
1 de 2 |
Introducción
Asegurar los datos con encriptación es de suma importancia en muchos aspectos de la administración de sistemas de hoy en día, y más aún cuando se trata de acceder a sistemas de forma remota. A diferencia de soluciones inseguras como telnet, rlogin o FTP, el protocolo SSH (Secure Shell) fue diseñado pensando en la seguridad. Utilizando criptografía de clave pública, autentifica tanto a los hosts como a los usuarios y encripta todo el intercambio de información posterior. Además, SSH puede utilizarse para establecer túneles de puertos, lo que -entre otras cosas- permite que un protocolo no cifrado transmita datos a través de una conexión SSH cifrada. La versión actual y recomendada del protocolo SSH es la 2.0. OpenSSH es una implementación libre y de código abierto del protocolo SSH.
Esta lección cubrirá la configuración básica del cliente OpenSSH así como el papel de las claves del servidor OpenSSH. También se discutirá el concepto de túneles de puertos SSH. Utilizaremos dos máquinas con la siguiente configuración:
Rol del equipo | Sistema Operativo | Dirección IP | Hostname | Usuario |
---|---|---|---|---|
Cliente |
Debian GNU/Linux 10 (buster) |
|
|
|
Servidor |
openSUSE Leap 15.1 |
|
|
|
Configuración y uso básico del cliente OpenSSH
Aunque el servidor y el cliente de OpenSSH vienen en paquetes separados, normalmente se puede instalar un metapaquete que proporcione ambos a la vez. Para establecer una sesión remota con el servidor SSH se utiliza el comando ssh
, especificando el usuario con el que se quiere conectar en la máquina remota y la dirección IP o el nombre de la máquina remota. La primera vez que se conecte a una máquina remota recibirá un mensaje como este:
carol@debian:~$ ssh ina@192.168.1.77 The authenticity of host '192.168.1.77 (192.168.1.77)' can't be established. ECDSA key fingerprint is SHA256:5JF7anupYipByCQm2BPvDHRVFJJixeslmppi2NwATYI. Are you sure you want to continue connecting (yes/no)?
Después de teclear sí
y pulsar Enter, se le pedirá la contraseña del usuario remoto. Si se introduce correctamente, se mostrará un mensaje de advertencia y se iniciará la sesión en el host remoto:
Warning: Permanently added '192.168.1.77' (ECDSA) to the list of known hosts. Password: Last login: Sat Jun 20 10:52:45 2020 from 192.168.1.4 Have a lot of fun... ina@halof:~>
Los mensajes se explican por sí mismos: como era la primera vez que establecía una conexión con el servidor remoto 192.168.1.77
, su autenticidad no podía ser comprobada con ninguna base de datos. Por lo tanto, el servidor remoto proporcionó una huella de clave ECDSA
de su clave pública (utilizando la función hash SHA256
). Una vez aceptada la conexión, la clave pública del servidor remoto se añadía a la base de datos de hosts conocidos, permitiendo así la autenticación del servidor para futuras conexiones. Esta lista de claves públicas de hosts conocidos se mantiene en el archivo known_hosts
ubicado en ~/.ssh
:
ina@halof:~> exit logout Connection to 192.168.1.77 closed. carol@debian:~$ ls .ssh/ known_hosts
Tanto .ssh
como known_hosts
fueron creados después de establecer la primera conexión remota. ~/.ssh
es el directorio por defecto para la configuración específica del usuario y la información de autenticación.
Note
|
También puede utilizar |
Si está utilizando el mismo usuario tanto en el host local como en el remoto, no es necesario especificar el nombre de usuario al establecer la conexión SSH. Por ejemplo, si está conectado como usuario carol
en debian
y quiere conectarse a halof
también como usuario carol
, simplemente escribiría ssh 192.168.1.77
o ssh halof
(si el nombre puede ser resuelto):
carol@debian:~$ ssh halof Password: Last login: Wed Jul 1 23:45:02 2020 from 192.168.1.55 Have a lot of fun... carol@halof:~>
Ahora suponga que establece una nueva conexión remota con un host que casualmente tiene la misma dirección IP que halof
(algo común si utiliza DHCP en su LAN). Se le advertirá de la posibilidad de un ataque man-in-the-middle:
carol@debian:~$ ssh john@192.168.1.77 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is SHA256:KH4q3vP6C7e0SEjyG8Wlz9fVlf+jmWJ5139RBxBh3TY. Please contact your system administrator. Add correct host key in /home/carol/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /home/carol/.ssh/known_hosts:1 remove with: ssh-keygen -f "/home/carol/.ssh/known_hosts" -R "192.168.1.77" ECDSA host key for 192.168.1.77 has changed and you have requested strict checking. Host key verification failed.
Como no se trata de un ataque man-in-the-middle, puede añadir con seguridad la huella de la clave pública del nuevo host a .ssh/known_hosts
. Como indica el mensaje, primero, puede utilizar el comando ssh-keygen -f "/home/carol/.ssh/known_hosts" -R "192.168.1.77"
para eliminar la clave ofensiva (alternativamente, puede optar por ssh-keygen -R 192.168.1.77
para eliminar todas las claves pertenecientes a 192.168.1.77
de ~/.ssh/known_hosts
). Entonces, podrá establecer una conexión con el nuevo host.
Inicio de sesión basado en claves
Puede configurar su cliente SSH para que no proporcione ninguna contraseña al iniciar la sesión, sino que utilice claves públicas. Este es el método preferido para conectarse a un servidor remoto vía SSH, ya que es mucho más seguro. Lo primero que tiene que hacer es crear un par de claves en la máquina cliente. Para hacer esto, usará ssh-keygen
con la opción -t
especificando el tipo de encriptación deseado (Elliptic Curve Digital Signature Algorithm en nuestro caso). A continuación, se le pedirá la ruta para guardar el par de claves (~/.ssh/
es conveniente, así como la ubicación por defecto) y una frase de contraseña. Aunque la frase de contraseña es opcional, se recomienda encarecidamente utilizarla siempre.
carol@debian:~/.ssh$ ssh-keygen -t ecdsa Generating public/private ecdsa key pair. Enter file in which to save the key (/home/carol/.ssh/id_ecdsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/carol/.ssh/id_ecdsa. Your public key has been saved in /home/carol/.ssh/id_ecdsa.pub. The key fingerprint is: SHA256:tlamD0SaTquPZYdNepwj8XN4xvqmHCbe8g5FKKUfMo8 carol@debian The key's randomart image is: +---[ECDSA 256]---+ | . | | o . | | = o o | | B * | | E B S o | | o & O | | @ ^ = | | *.@ @. | | o.o+B+o | +----[SHA256]-----+
Note
|
Al crear el par de claves, puede pasar a |
El comando anterior produjo dos archivos más en su directorio ~/.ssh
:
carol@debian:~/.ssh$ ls id_ecdsa id_ecdsa.pub known_hosts
id_ecdsa
-
Esta es su clave privada.
id_ecdsa.pub
-
Esta es su clave pública.
Note
|
En la criptografía asimétrica (también conocida como criptografía de clave pública), las claves públicas y privadas están relacionadas matemáticamente entre sí de manera que lo que se cifra con una sólo puede descifrarse con la otra. |
Lo siguiente que debe hacer es añadir su clave pública al archivo ~/.ssh/authorized_keys
del usuario con el que quiere iniciar sesión en el host remoto (si el directorio ~/.ssh
no existe todavía, tendrá que crearlo primero). Puede copiar su clave pública en el servidor remoto de varias maneras: usando una memoria USB, a través del comando scp
- que transferirá el archivo usando SSH - o pasando con un cat el contenido de su clave pública y pasándolo a ssh
de esta manera:
carol@debian:~/.ssh$ cat id_ecdsa.pub |ssh ina@192.168.1.77 'cat >> .ssh/authorized_keys' Password:
Una vez que su clave pública haya sido añadida al archivo authorized_keys
en el host remoto, puede enfrentarse a dos escenarios cuando intente establecer una nueva conexión:
-
Si no ha proporcionado una frase de contraseña al crear el par de claves, se iniciará la sesión automáticamente. Aunque es conveniente, este método puede ser inseguro dependiendo de la situación:
carol@debian:~$ ssh ina@192.168.1.77 Last login: Thu Jun 25 20:31:03 2020 from 192.168.1.55 Have a lot of fun... ina@halof:~>
-
Si proporcionó una frase de contraseña al crear el par de claves, tendrá que introducirla en cada conexión de la misma manera que si fuera una contraseña. Aparte de la clave pública, este método añade una capa extra de seguridad en forma de frase de contraseña y puede — por tanto — considerarse más seguro. Sin embargo, en lo que respecta a la comodidad, es exactamente lo mismo que tener que introducir una contraseña cada vez que se establece una conexión. Si no utiliza una frase de contraseña y alguien consigue obtener su archivo de clave SSH privada, tendría acceso a todos los servidores en los que esté instalada su clave pública.
carol@debian:~/.ssh$ ssh ina@192.168.1.77 Enter passphrase for key '/home/carol/.ssh/id_ecdsa': Last login: Thu Jun 25 20:39:30 2020 from 192.168.1.55 Have a lot of fun... ina@halof:~>
Sin embargo, hay una forma que combina seguridad y comodidad: utilizar el agente de autenticación SSH (ssh-agent
). El agente de autenticación necesita generar su propio shell y mantendrá sus claves privadas -para la autenticación con clave pública- en memoria durante el resto de la sesión. Veamos cómo funciona con un poco más de detalle:
-
Utilice
ssh-agent
para iniciar un nuevo shell Bash:carol@debian:~/.ssh$ ssh-agent /bin/bash carol@debian:~/.ssh$
-
Utilice el comando
ssh-add
para añadir su clave privada a una zona segura de la memoria. Si proporciona una frase de contraseña al generar el par de claves (lo que se recomienda para mayor seguridad) se le pedirá:carol@debian:~/.ssh$ ssh-add Enter passphrase for /home/carol/.ssh/id_ecdsa: Identity added: /home/carol/.ssh/id_ecdsa (carol@debian)
Una vez añadida su identidad, podrá iniciar sesión en cualquier servidor remoto en el que esté presente su clave pública sin tener que volver a escribir su frase de acceso. Es una práctica habitual en los ordenadores de sobremesa modernos realizar este comando al arrancar el ordenador, ya que permanecerá en la memoria hasta que se apague el ordenador (o se descargue la clave manualmente).
Completemos esta sección enumerando los cuatro tipos de algoritmos de clave pública que se pueden especificar con ssh-keygen
:
RSA
-
Llamado así por sus creadores Ron Rivest, Adi Shamir y Leonard Adleman, fue publicado en 1977. Se considera seguro y sigue siendo muy utilizado en la actualidad. Su tamaño mínimo de clave es de 1024 bits (por defecto es de 2048).
DSA
-
El Algoritmo de Firma Digital (DSA) ha demostrado ser inseguro y ha sido obviado a partir de OpenSSH 7.0. Las claves DSA deben tener exactamente 1024 bits de longitud.
ecdsa
-
El Algoritmo de Firma Digital de Curva Elíptica es una mejora del DSA y, por tanto, se considera más seguro. Utiliza la criptografía de curva elíptica. La longitud de la clave ECDSA está determinada por uno de los tres tamaños posibles de la curva elíptica en bits: 256, 384 o 521.
ed25519
-
Se trata de una implementación de
EdDSA
— Algoritmo de Firma Digital de la Curva de Edwardsm — que utiliza la curva 25519 más fuerte. Se considera la más segura de todas. Todas las claves Ed25519 tienen una longitud fija de 256 bits.
Note
|
Si se invoca sin especificar |
El papel de las claves del servidor OpenSSH
El directorio de configuración global de OpenSSH se ubica en el directorio /etc
:
halof:~ # tree /etc/ssh /etc/ssh ├── moduli ├── ssh_config ├── ssh_host_dsa_key ├── ssh_host_dsa_key.pub ├── ssh_host_ecdsa_key ├── ssh_host_ecdsa_key.pub ├── ssh_host_ed25519_key ├── ssh_host_ed25519_key.pub ├── ssh_host_rsa_key ├── ssh_host_rsa_key.pub └── sshd_config 0 directories, 11 files
Aparte de moduli
y los archivos de configuración para el cliente (ssh_config
) y el servidor (sshd_config
), encontrará cuatro pares de claves — un par de claves para cada algoritmo soportado — que se crean cuando se instala el servidor OpenSSH. Como ya se ha dicho, el servidor utiliza estas claves de host para identificarse ante los clientes según sea necesario. Su patrón de nombres es el siguiente:
- Claves privadas
-
ssh_host_
prefix + algorithm +key
suffix (p. ej.:ssh_host_rsa_key
) - Claves públicas (o huellas de clave pública)
-
ssh_host_
prefix + algorithm +key.pub
suffix (p. ej.:ssh_host_rsa_key.pub
)
Note
|
Una huella digital se crea aplicando una función hash criptográfica a una clave pública. Como son más cortas que las claves a las que se refieren, resultan útiles para simplificar ciertas tareas de gestión de claves. |
Los permisos de los archivos que contienen las claves privadas son 0600
o -rw-------
: sólo pueden ser leídos y escritos por el propietario (root
). Por otro lado, todos los archivos de claves públicas también son legibles por los miembros del grupo propietario y por todos los demás (0644
o -rw-r—r--
):
halof:~ # ls -l /etc/ssh/ssh_host_* -rw------- 1 root root 1381 Dec 21 20:35 /etc/ssh/ssh_host_dsa_key -rw-r--r-- 1 root root 605 Dec 21 20:35 /etc/ssh/ssh_host_dsa_key.pub -rw------- 1 root root 505 Dec 21 20:35 /etc/ssh/ssh_host_ecdsa_key -rw-r--r-- 1 root root 177 Dec 21 20:35 /etc/ssh/ssh_host_ecdsa_key.pub -rw------- 1 root root 411 Dec 21 20:35 /etc/ssh/ssh_host_ed25519_key -rw-r--r-- 1 root root 97 Dec 21 20:35 /etc/ssh/ssh_host_ed25519_key.pub -rw------- 1 root root 1823 Dec 21 20:35 /etc/ssh/ssh_host_rsa_key -rw-r--r-- 1 root root 397 Dec 21 20:35 /etc/ssh/ssh_host_rsa_key.pub
Puede ver las huellas digitales de las claves pasando a ssh-keygen
la opción -l
. También debe proporcionar la opción -f
para especificar la ruta del archivo de claves:
halof:~ # ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key 256 SHA256:8cnPrinC49ZHc+/9Ai5pV+1JfZ4WBRZhd3rDOsc2zlA root@halof (ED25519) halof:~ # ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub 256 SHA256:8cnPrinC49ZHc+/9Ai5pV+1JfZ4WBRZhd3rDOsc2zlA root@halof (ED25519)
Para ver la huella digital de la llave, así como su arte aleatorio, basta con añadir la opción -v
de esta manera:
halof:~ # ssh-keygen -lv -f /etc/ssh/ssh_host_ed25519_key.pub 256 SHA256:8cnPrinC49ZHc+/9Ai5pV+1JfZ4WBRZhd3rDOsc2zlA root@halof (ED25519) +--[ED25519 256]--+ | +oo| | .+o.| | . ..E.| | + . +.o| | S + + *o| | ooo Oo=| | . . . =o+.==| | = o =oo o=o| | o.o +o+..o.+| +----[SHA256]-----+
Túneles de puertos SSH
OpenSSH cuenta con un mecanismo de reenvío muy potente por el que el tráfico de un puerto de origen se tuneliza -y encripta- a través de un proceso SSH que luego lo redirige a un puerto de un host de destino. Este mecanismo se conoce como túnel de puertos o reenvío de puertos y tiene importantes ventajas como las siguientes:
-
Permite saltarse los cortafuegos para acceder a los puertos de los hosts remotos.
-
Facilita el acceso desde el exterior a un host de su red privada.
-
Proporciona encriptación para todo el intercambio de datos.
A grandes rasgos, podemos diferenciar entre túnel de puerto local y remoto.
Túnel de puerto local
Se define un puerto localmente para reenviar el tráfico al host de destino a través del proceso SSH que se encuentra en el medio. El proceso SSH puede ejecutarse en el host local o en un servidor remoto. Por ejemplo, si por alguna razón quisiera tunelizar una conexión a www.gnu.org
a través de SSH usando el puerto 8585
en su máquina local, haría algo como esto:
carol@debian:~$ ssh -L 8585:www.gnu.org:80 debian carol@debian's password: Linux debian 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) x86_64 Los programas incluidos en el sistema Debian GNU/Linux son software libre: (...) Last login: Sun Jun 28 13:47:27 2020 from 127.0.0.1
La explicación es la siguiente: con el parámetro -L
, especificamos el puerto local 8585
para conectar con el puerto http 80
en www.gnu.org
utilizando el proceso SSH que se ejecuta en debian
— nuestro localhost. Podríamos haber escrito ssh -L 8585:www.gnu.org:80 localhost
con el mismo efecto. Si ahora utiliza un navegador web para ir a http://localhost:8585
, será redirigido a www.gnu.org
. Para la demostración, utilizaremos lynx
(el clásico navegador web en modo texto):
carol@debian:~$ lynx http://localhost:8585 (...) * Back to Savannah Homepage * Not Logged in * Login * New User * This Page * Language * Clean Reload * Printer Version * Search * _ (...)
Si quisiera hacer exactamente lo mismo pero conectándose a través de un proceso SSH ejecutado en halof
, habría procedido así:
carol@debian:~$ ssh -L 8585:www.gnu.org:80 -Nf ina@192.168.1.77 Enter passphrase for key '/home/carol/.ssh/id_ecdsa': carol@debian:~$ carol@debian:~$ lynx http://localhost:8585 (...) * Back to Savannah Homepage * Not Logged in * Login * New User * This Page * Language * Clean Reload * Printer Version * Search * _ (...)
Es importante que anote tres detalles en el comando:
-
Gracias a la opción
-N
no hemos entrado enhalof
sino que hemos hecho el reenvío de puertos. -
La opción
f
le indica a SSH que se ejecute en segundo plano. -
Especificamos el usuario
ina
para hacer el reenvío:ina@192.168.1.77
Túnel de puerto remoto
En el tunelado de puertos remotos (o reenvío inverso de puertos) el tráfico que llega a un puerto del servidor remoto es reenviado al proceso SSH que se ejecuta en su host local, y de ahí al puerto especificado en el servidor de destino (que también puede ser su máquina local). Por ejemplo, digamos que quiere que alguien de fuera de su red acceda al servidor web Apache que se ejecuta en su máquina local a través del puerto 8585
del servidor SSH que se ejecuta en halof
(192.168.1.77
). Usted procedería con el siguiente comando:
carol@debian:~$ ssh -R 8585:localhost:80 -Nf ina@192.168.1.77 Enter passphrase for key '/home/carol/.ssh/id_ecdsa': carol@debian:~$
Ahora cualquiera que establezca una conexión con halof
en el puerto 8585
verá la página de inicio por defecto de Debian
Apache2:
carol@debian:~$ lynx 192.168.1.77:8585 (...) Apache2 Debian Default Page: It works (p1 of 3) Debian Logo Apache2 Debian Default Page It works! This is the default welcome page used to test the correct operation of the Apache2 server after installation on Debian systems. If you can read this page, it means that the Apache HTTP server installed at this site is working properly. You should replace this file (located at /var/www/html/index.html) before continuing to operate your HTTP server. (...)
Note
|
Existe un tercer tipo de reenvío de puertos, más complejo, que queda fuera del ámbito de esta lección: el reenvío dinámico de puertos. En lugar de interactuar con un solo puerto, este tipo de reenvío utiliza varias comunicaciones TCP a través de un rango de puertos. |
Túneles X11
Ahora que entiende los túneles de puertos, vamos a completar esta lección hablando del túnel X11 (también conocido como X11forwarding). A través de un túnel X11, el X Window System del host remoto es reenviado a su máquina local. Para ello, sólo tiene que pasar a ssh
la opción -X
:
carol@debian:~$ ssh -X ina@halof ...
Ahora puede lanzar una aplicación gráfica como el navegador web firefox
con el siguiente resultado: la aplicación se ejecutará en el servidor remoto, pero su visualización se remitirá a su host local.
Si inicia una nueva sesión SSH con la opción -x
en su lugar, el X11forwarding se desactivará. Intente iniciar firefox
ahora y obtendrá un error como el siguiente:
carol@debian:~$ ssh -x ina@halof carol@192.168.0.106's password: (...) ina@halof:~$ firefox (firefox-esr:1779): Gtk-WARNING **: 18:45:45.603: Locale not supported by C library. Using the fallback 'C' locale. Error: no DISPLAY environment variable specified
Note
|
Las tres directivas de configuración relacionadas con el reenvío de puertos locales, el reenvío de puertos remotos y el reenvío de X11 son |
Ejercicios guiados
-
Conectado como usuario
sonya
en su máquina cliente, realice las siguientes tareas SSH en el servidor remotohalof
:-
Ejecute el comando para listar el contenido de
~/.ssh
como usuarioserena
en el host remoto; luego vuelva a su terminal local. -
Ingrese como usuario
serena
en el host remoto. -
Ingrese como usuario
sonya
en el host remoto. -
Borre todas las claves pertenecientes a
halof
de su archivo local~/.ssh/known_hosts
. -
En su máquina cliente, cree un par de claves
ecdsa
de 256 bits. -
En su máquina cliente, cree un par de claves
ed25519
de 256 bits.
-
-
Ponga los siguientes pasos en el orden correcto para establecer una conexión SSH usando el agente de autenticación SSH:
-
En el cliente, inicie un nuevo shell Bash para el agente de autenticación con
ssh-agent /bin/bash
. -
En el cliente, cree un par de claves con
ssh-keygen
. -
En el cliente, añada su clave privada a un área segura de la memoria con
ssh-add
. -
Añada la clave pública de su cliente al archivo
~/.ssh/authorized_keys
del usuario con el que quiere iniciar sesión en el host remoto. -
Si no existe ya, cree
~/.ssh
para el usuario con el que quiere iniciar sesión en el servidor. -
Conéctese al servidor remoto.
El orden correcto es:
Paso 1:
Paso 2:
Paso 3:
Paso 4:
Paso 5:
Paso 6:
-
-
En cuanto al port forwarding, qué opción y directiva se utiliza para los siguientes tipos de túneles:
Tipo de túnel | Opción | Directiva |
---|---|---|
Local |
||
Remoto o Reverso |
||
X |
-
Suponga que escribe el comando
ssh -L 8888:localhost:80 -Nf ina@halof
en el terminal de su máquina cliente. Todavía en la máquina cliente, apunta un navegador ahttp://localhost:8888
. ¿Qué obtendrá?
Ejercicios de exploración
-
Con respecto a las directivas de seguridad SSH:
-
Qué directiva se utiliza en
/etc/ssh/sshd_config
para habilitar los inicios de sesiónroot
: -
¿Qué directiva usaría en
/etc/ssh/sshd_config
para especificar sólo una cuenta local para aceptar conexiones SSH:
-
-
Cuando se utiliza el mismo usuario tanto en el cliente como en el servidor, ¿qué comando
ssh
se puede utilizar para transferir la clave pública del cliente al servidor para poder iniciar sesión a través de la autenticación de clave pública? -
Cree dos túneles de puertos locales en un solo comando reenviando los puertos locales no privilegiados 8080 y 8585 a través del servidor remoto
halof
a los sitios webwww.gnu.org
ywww.melpa.org
, respectivamente. Utilice el usuarioina
en el servidor remoto y no olvide utilizar los interruptores-Nf
:
Resumen
En esta lección hemos hablado de OpenSSH 2, que utiliza el protocolo Secure Shell para cifrar las comunicaciones entre el servidor y el cliente. Ha aprendido:
-
Cómo iniciar sesión en un servidor remoto.
-
Cómo ejecutar comandos de forma remota.
-
Cómo crear pares de claves de autenticación.
-
Cómo establecer inicios de sesión basados en claves.
-
Cómo utilizar el agente de autenticación para mayor seguridad y comodidad.
-
Los algoritmos de clave pública soportados por OpenSSH:
RSA
,DSA
,ecdsa
,ed25519
. -
El papel de las claves de host OpenSSH.
-
Cómo crear túneles de puertos: local, remoto y X.
El siguiente comando fue discutido en esta lección:
ssh
-
Acceder o ejecutar comandos en una máquina remota.
ssh-keygen
-
Generar, gestionar y convertir claves de autenticación.
ssh-agent
-
Agente de autenticación OpenSSH.
ssh-add
-
Añade identidades de clave privada al agente de autenticación.
Respuestas a los ejercicios guiados
-
Conectado como usuario
sonya
en su máquina cliente, realice las siguientes tareas SSH en el servidor remotohalof
:-
Ejecute el comando para listar el contenido de
~/.ssh
como usuarioserena
en el host remoto; luego vuelva a su terminal local.ssh serena@halof ls .ssh
-
Ingrese como usuario
serena
en el host remoto.ssh serena@halof
-
Ingrese como usuario
sonya
en el host remoto.ssh halof
-
Borre todas las claves pertenecientes a
halof
de su archivo local~/.ssh/known_hosts
.ssh-keygen -R halof
-
En su máquina cliente, cree un par de claves
ecdsa
de 256 bits.ssh-keygen -t ecdsa -b 256
-
En su máquina cliente, cree un par de claves
ed25519
de 256 bits.ssh-keygen -t ed25519
-
-
Ponga los siguientes pasos en el orden correcto para establecer una conexión SSH usando el agente de autenticación SSH:
-
En el cliente, inicie un nuevo shell Bash para el agente de autenticación con
ssh-agent /bin/bash
. -
En el cliente, cree un par de claves con
ssh-keygen
. -
En el cliente, añada su clave privada a un área segura de la memoria con
ssh-add
. -
Añada la clave pública de su cliente al archivo
~/.ssh/authorized_keys
del usuario con el que quiere iniciar sesión en el host remoto. -
Si no existe ya, cree
~/.ssh
para el usuario con el que quiere iniciar sesión en el servidor. -
Conéctese al servidor remoto.
El orden correcto es:
Paso 1:
En el cliente, cree un par de claves utilizando
ssh-keygen
.Paso 2:
Si no existe ya, cree
~/.ssh
para el usuario con el que quiere iniciar sesión en el servidor.Paso 3:
Agregue la clave pública de su cliente al archivo
~/.ssh/authorized_keys
del usuario con el que quiere iniciar sesión en el host remoto.Paso 4:
En el cliente, inicie un nuevo shell Bash para el agente de autenticación con
ssh-agent /bin/bash
.Paso 5:
En el cliente, agregue su clave privada a una zona segura de la memoria con
ssh-add
.Paso 6:
Conéctese con el servidor remoto.
-
-
En cuanto al port forwarding, qué opción y directiva se utiliza para los siguientes tipos de túneles:
Tipo de túnel Opción Directiva Local
-L
AllowTcpForwarding
Remoto o Reverso
-R
GatewayPorts
X
-X
X11Forwarding
-
Suponga que escribe el comando
ssh -L 8888:localhost:80 -Nf ina@halof
en el terminal de su máquina cliente. Todavía en la máquina cliente, apunta un navegador ahttp://localhost:8888
. ¿Qué obtendrá?La página de inicio del servidor web de
halof
, como se entiendelocalhost
desde la perspectiva del servidor.
Respuestas a los ejercicios de exploración
-
Con respecto a las directivas de seguridad SSH:
-
Qué directiva se utiliza en
/etc/ssh/sshd_config
para habilitar los inicios de sesiónroot
:PermitRootLogin
-
¿Qué directiva usaría en
/etc/ssh/sshd_config
para especificar sólo una cuenta local para aceptar conexiones SSH:AllowUsers
-
-
Cuando se utiliza el mismo usuario tanto en el cliente como en el servidor, ¿qué comando
ssh
se puede utilizar para transferir la clave pública del cliente al servidor para poder iniciar sesión a través de la autenticación de clave pública?ssh-copy-id
-
Cree dos túneles de puertos locales en un solo comando reenviando los puertos locales no privilegiados 8080 y 8585 a través del servidor remoto
halof
a los sitios webwww.gnu.org
ywww.melpa.org
, respectivamente. Utilice el usuarioina
en el servidor remoto y no olvide utilizar los interruptores-Nf
:ssh -L 8080:www.gnu.org:80 -L 8585:www.melpa.org:80 -Nf ina@halof