SSH

18 de marzo del 2023

Introducción histórica

En los primeros días de internet se creó el protocolo telnet para poder comunicar varios ordenadores, pero tenía el problema de que no estaba cifrado, por lo que cualquiera que se metiera en medio podía leer la comunicación sin problema, por eso se creó SSH (Secure Shell)

Cifrado de `SSH`

El sistema de cifrado de SSH funciona mediante el sistema de clave pública y clave privada, de manera que si se encripta la comunicación con una de las dos claves, solo puede ser descifrada por la otra clave

¿Y por qué hay una clave pública y una clave privada? La clave pública es la que le das a todo el mundo y la clave privada es la que solo tienes que poseer tú.

De manera que si te quieres comunicar con otro equipo por SSH, primero le das tu clave pública, a continuación encriptas el mensaje con tu clave privada y solo se puede desencriptar el mensaje con la clave pública que le has dado al otro equipo

De la misma manera ocurre al revés, si el otro equipo te quiere mandar un mensaje, lo encripta con tu clave pública y solo se puede desencriptar con la clave privada que solo tú posees

Requerimentos `SSH`

Servicio `SSH`

Para poder usar SSH necesitas tener un servicio de SSH. En Linux normalmente ya viene instalado, pero si no es así lo puedes instalar mediante

	
		!apt install openssh-server

Durante el proceso de instalación, te pedirá tu ubicación para ajustar el time zone

A continuación, levantamos el servicio

	
		!systemctl enable ssh

Cliente `SSH`

Una vez tengas el servicio necesitas un cliente, aunque en Linux suele venir instalado, pero si no es así lo puedes instalar mediante

	
		!apt install openssh-client

Conexión por `SSH`

Para conectarte por SSH necesitas introducir el comando ssh <user>@<ip>

	
		!ssh root@172.17.0.1

	
		The authenticity of host '172.17.0.1 (172.17.0.1)' can't be established.
ECDSA key fingerprint is SHA256:M+qsqSC4HiYztm1ij8iDkh9KHJz+pxrTm9GTZIf2N9k.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Como puedes ver, la primera vez te pregunta si quieres guardar el fingerprint, esto es para que si la próxima vez que te conectes a la misma máquina (a la misma clave pública) ha cambiado el fingerprint debes tener cuidado porque puede haber algo peligroso, como que se hagan pasar por esa máquina.

Si nos fiamos introducimos yes

	
		!ssh root@172.17.0.1

	
		The authenticity of host '172.17.0.1 (172.17.0.1)' can't be established.
ECDSA key fingerprint is SHA256:M+qsqSC4HiYztm1ij8iDkh9KHJz+pxrTm9GTZIf2N9k.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '172.17.0.1' (ECDSA) to the list of known hosts.
root@172.17.0.1's password:

A continuación, la máquina a la que nos conectamos nos pide la contraseña, la introducimos y ya estaremos dentro de la máquina

	
		!ssh root@172.17.0.1

	
		The authenticity of host '172.17.0.1 (172.17.0.1)' can't be established.
ECDSA key fingerprint is SHA256:M+qsqSC4HiYztm1ij8iDkh9KHJz+pxrTm9GTZIf2N9k.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '172.17.0.1' (ECDSA) to the list of known hosts.
root@172.17.0.1's password:
Welcome to Ubuntu 20.04.5 LTS (GNU/Linux 5.15.0-58-generic x86_64)
* Documentation:  https://help.ubuntu.com
* Management:     https://landscape.canonical.com
* Support:        https://ubuntu.com/advantage
1 device has a firmware upgrade available.
Run `fwupdmgr get-upgrades` for more information.
* Introducing Expanded Security Maintenance for Applications.
   Receive updates to over 25,000 software packages with your
   Ubuntu Pro subscription. Free for personal use.
     https://ubuntu.com/pro
Se pueden aplicar 0 actualizaciones de forma inmediata.
Your Hardware Enablement Stack (HWE) is supported until April 2025.
Last login: Thu Dec  1 16:32:23 2022 from 127.0.0.1
root@172.17.0.1:~$

Conexión sin necesidad de contraseña

Como hemos visto, cuando nos conectamos nos pide la contraseña de la máquina de destino, pero si es una máquina a la que nos vamos a conectar mucho, podemos hacer que no nos pida la contraseña cada vez que nos queramos conectar.

Para ello, en primer lugar generamos una clave ssh mediante ssh-keygen

	
		!ssh-keygen

	
		Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa
Your public key has been saved in /root/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:4HxRXkVkcK5kNXNyzakfQ6t8a24wRGCUYz4s5KL5ZEc root@e108f6f395b3
The key's randomart image is:
+---[RSA 3072]----+
|          o+==@.=|
|         +.= * Oo|
|      . + = = + .|
|     o o E * + + |
|      = S . = o o|
|     o + .   = o |
|      + .     + .|
|       .       + |
|              +. |
+----[SHA256]-----+

Como vemos, primero nos pregunta dónde queremos guardar la clave, si no introducimos nada nos la guarda en la ruta por defecto. Y a continuación una frase para generar la clave, **si escribes una frase debes recordarla siempre**. Además, si escribes una frase, te la pedirá cada vez que intentes acceder a la clave, por lo que cada vez que queramos acceder a la máquina por medio de SSH, no nos pedirá la contraseña de la máquina, pero sí esta frase. Por lo que tú eliges si no introduces una frase para que nunca te la pida, o si sí la introduces y siempre las vas a meter.

A continuación, le pedimos a la máquina remota que se guarde nuestra clave mediante ssh-copy-id <user>@<id>:

	
		!ssh-copy-id root@172.17.0.1:

	
		/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@172.17.0.1's password:
Number of key(s) added: 1
Now try logging into the machine, with:   "ssh 'root@172.17.0.1'"
and check to make sure that only the key(s) you wanted were added.
root@103b6040196a:/# ssh root@172.17.0.1
Welcome to Ubuntu 20.04.5 LTS (GNU/Linux 5.15.0-58-generic x86_64)
* Documentation:  https://help.ubuntu.com
* Management:     https://landscape.canonical.com
* Support:        https://ubuntu.com/advantage
4 devices have a firmware upgrade available.
Run `fwupdmgr get-upgrades` for more information.
58 updates can be applied immediately.
41 of these updates are standard security updates.
To see these additional updates run: apt list --upgradable
New release '22.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.
Your Hardware Enablement Stack (HWE) is supported until April 2025.
Last login: Thu Feb  2 08:05:48 2023 from 172.17.0.2
(base) root@172.17.0.1:~$

Usar la terminal remota por `SSH`

A lo mejor no nos hace falta tener que meternos a la máquina remota porque solo necesitamos ejecutar un solo comando, por lo que podemos usar remotamente su terminal añadiendo el flag -t al comando SSH, es decir, mediante ssh -t <user>@<id> <command>

	
		!ssh -t root@172.17.0.1 ping -c 4 google.com

	
		PING google.com (172.217.168.174) 56(84) bytes of data.
64 bytes from mad07s10-in-f14.1e100.net (172.217.168.174): icmp_seq=1 ttl=111 time=2.94 ms
64 bytes from mad07s10-in-f14.1e100.net (172.217.168.174): icmp_seq=2 ttl=111 time=2.55 ms
64 bytes from mad07s10-in-f14.1e100.net (172.217.168.174): icmp_seq=3 ttl=111 time=2.78 ms
64 bytes from mad07s10-in-f14.1e100.net (172.217.168.174): icmp_seq=4 ttl=111 time=2.69 ms
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 2.550/2.739/2.940/0.142 ms
Connection to 172.17.0.1 closed.

Como se puede ver se realiza el comando en la máquina remota y cuando termina, en la última línea nos dice que se cierra la conexión

Proxy `SSH`

Si estás navegando en un lugar no muy seguro, o en un lugar que tiene un proxy que no te deja acceder a algunos puertos, puedes navegar a través del proxy de otra máquina mediante SSH, esto se puede hacer añadiendo el flag -D y el puerto por el que quieres realizar la conexión al proxy remoto, como el puerto para el tcp/ip es el 9999 el comando podría quedar como ssh -D 9999 <user>@<id>

Para que esto se vea mejor, antes de ejecutarlo obtengo mi IP pública

	
		!curl ifconfig.me

	
		188.127.184.59

Ahora uso el proxy de un servidor web que tengo levantado

	
		!ssh -D 9999 root@194.62.99.222

	
		Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-53-generic x86_64)
* Documentation:  https://help.ubuntu.com
* Management:     https://landscape.canonical.com
* Support:        https://ubuntu.com/advantage
  System information as of Wed Feb 22 06:08:51 AM UTC 2023
  System load:           0.02978515625
  Usage of /:            11.7% of 24.53GB
  Memory usage:          33%
  Swap usage:            0%
  Processes:             89
  Users logged in:       0
  IPv4 address for eth0: 194.62.99.222
  IPv4 address for eth1: 10.7.0.168
  IPv6 address for eth2: 2a04:3542:8000:1000:d48a:cbff:fefb:5b1
0 updates can be applied immediately.
The list of available updates is more than a week old.
To check for new updates run: sudo apt update
Last login: Wed Feb 22 06:02:35 2023 from 188.127.184.59
root@server1:~#

Cambio la configuración del proxy de mi ordenador

Ahora vuelvo a mirar mi IP pública, pero usando el proxy recientemente configurado

	
		!curl -x socks5h://localhost:9999 ifconfig.me

	
		194.62.99.222

Vemos que obtenemos la IP pública del servidor

Interfaz gráfica remota por `SSH`

En Linux la interfaz gráfica es un servidor, por lo que nos podemos beneficiar de ello y podemos ejecutar programas con interfaces gráficas que están en una máquina remota por SSH, para ello hay que usar el flag -X. El comando quedaría ssh -X <user>@<id>

Primero entro a mi servidor e instalo xeyes mediante sudo apt install x11-apps y después lo ejecuto remotamente desde mi ordenador

	
		!ssh -X root@194.62.99.222

	
		Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-53-generic x86_64)
Last login: Wed Feb 22 06:39:52 2023 from 188.127.184.59
/usr/bin/xauth:  file /root/.Xauthority does not exist
root@server1:~sudo apt install x11-apps
root@server1:~#xeyes

Ahora en mi ordenador se abre la ventana de xeyes pero no se está ejecutando en mi ordenador

Tunel `SSH`

Como he comentado, he levantado un servidor al que tengo acceso por SSH

	
		!ssh root@194.62.99.222

	
		Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-53-generic x86_64)
Last login: Wed Feb 22 06:40:58 2023 from 188.127.184.59
root@server1:~#

Y levanto también un segundo servidor desde el que tengo acceso desde el server1, pero no tengo acceso desde mi ordenador

A continuación, intento acceder al server2 desde mi ordenador y vemos que no puedo

	
		!ssh root@194.62.99.235

	
		ssh: connect to host 194.62.99.235 port 22: Connection timed out

Y a continuación intento acceder al server2 desde el server1 y vemos que sí puedo

	
		!root@server1:~# ssh root@10.7.2.228

	
		Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-53-generic x86_64)
Last login: Wed Feb 22 06:59:01 2023 from 10.7.0.168
root@server2:~#

Así que lo que creamos es un túnel desde mi ordenador hasta el server2 a través del server1, para ello usamos el flag -L. Para crear el túnel hay que indicar el puerto de tu ordenador en el que vas a crear el túnel, a continuación la IP de destino del túnel, el puerto por el que irá el túnel y por último el dispositivo que creará el túnel. Quedaría así

ssh -L &ltHOST PORT&gt:&ltDEST IP&gt:&ltTUNNEL PORT&gt &ltTUNNEL CREATOR USER&gt@&ltTUNNEL CREATOR IP&gt

Veámoslo con mi ejemplo, tengo el server1 con una IP pública que podemos llamar ip_pub1 y al que tengo acceso por SSH y una IP privada que podemos llamar ip_priv1 que está dentro de la misma red que server2. Y tengo el server2 con una IP pública que podemos llamar ip_pub2 a la que no tengo acceso por SSH y una IP que podemos llamar ip_priv2 dentro de la misma red de server1

Primero creo el túnel

ssh -L host_port:ip_priv2:22 root@ip_pub1

He creado un túnel hasta la IP privada del server2 a través de la IP pública del server1

Por último, para conectarme al server2 lo hago a través del localhost y del puerto del host que he declarado en el túnel

ssh -p 2020 root@localhost

Vamos a verlo en la realidad, las IPs de mis servidores son

server1:

IP pública: 194.62.99.222
IP privada: 10.7.0.168

server2:

IP pública: 194.62.99.235
IP privada: 10.7.2.228

Primero creo el túnel

	
		!ssh -L 2020:10.7.2.228:22 root@194.62.99.222

	
		Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-53-generic x86_64)
* Documentation:  https://help.ubuntu.com
* Management:     https://landscape.canonical.com
* Support:        https://ubuntu.com/advantage
  System information as of Wed Feb 22 11:13:39 AM UTC 2023
  System load:           0.0
  Usage of /:            13.3% of 24.53GB
  Memory usage:          36%
  Swap usage:            0%
  Processes:             91
  Users logged in:       1
  IPv4 address for eth0: 194.62.99.222
  IPv4 address for eth1: 10.7.0.168
  IPv6 address for eth2: 2a04:3542:8000:1000:d48a:cbff:fefb:5b1
101 updates can be applied immediately.
60 of these updates are standard security updates.
To see these additional updates run: apt list --upgradable
Last login: Wed Feb 22 09:29:52 2023 from 188.127.184.59
]0;root@server1: ~root@server1:~# ^C
]0;root@server1: ~root@server1:~#

Con el túnel creado ya me puedo conectar al server2 desde mi ordenador

	
		!ssh -p 2020 root@localhost

	
		Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-53-generic x86_64)
* Documentation:  https://help.ubuntu.com
* Management:     https://landscape.canonical.com
* Support:        https://ubuntu.com/advantage
  System information as of Wed Feb 22 11:14:15 AM UTC 2023
  System load:           0.0
  Usage of /:            13.3% of 24.53GB
  Memory usage:          33%
  Swap usage:            0%
  Processes:             90
  Users logged in:       0
  IPv4 address for eth0: 194.62.99.235
  IPv4 address for eth1: 10.7.2.228
  IPv6 address for eth2: 2a04:3542:8000:1000:d48a:cbff:fefb:7f47
* Strictly confined Kubernetes makes edge and IoT secure. Learn how MicroK8s
   just raised the bar for easy, resilient and secure K8s cluster deployment.
   https://ubuntu.com/engage/secure-kubernetes-at-the-edge
101 updates can be applied immediately.
60 of these updates are standard security updates.
To see these additional updates run: apt list --upgradable
Last login: Wed Feb 22 11:14:16 2023 from 10.7.0.168
]0;root@server2: ~root@server2:~# ^C
]0;root@server2: ~root@server2:~#

Conexión reversa

Volvamos a suponer que me quiero conectar al server2, pero ahora no puedo hacer, por la razón que sea, un túnel desde el server1. Lo que podemos hacer es crear una conexión reversa desde otro servidor.

Supongamos que tengo un tercer servidor, llamado server3, al que se tiene acceso por SSH desde cualquier lado, es decir, tanto yo desde mi ordenador como el server2 tienen acceso. Por lo que si podemos acceder físicamente al server2 se puede hacer una conexión reversa desde el server2 al server3

ssh -R &ltserver3port&gt:localhost:22 root@&ltIPserver3&gt

Con esto, lo que he hecho es habilitar una conexión desde el server3 al server2 (cosa que antes no se podía), a través del localhost y puerto server3port del server3

Ahora desde mi ordenador me puedo conectar al server3 y desde el server3 me puedo conectar al server2 mediante

ssh -p &ltserver3port&gt root@localhost

Veámoslo con los datos de mis servidores

server2:

IP pública: 194.62.99.235

server3:

IP pública: 194.62.96.236

Primero hago la conexión reversa desde el server2 al server3

	
		!root@server2:~# ssh -R 2020:localhost:22 root@194.62.96.236

	
		Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-53-generic x86_64)
Last login: Wed Feb 22 15:25:58 2023 from 188.127.184.59
root@server3:~#

Ahora me conecto al server3

	
		!ssh root@194.62.96.236

	
		Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-53-generic x86_64)
Last login: Wed Feb 22 15:12:19 2023 from 188.127.184.59
root@server3:~#

Y ahora que estoy en el server3 me conecto al server2

	
		!root@server3:~# ssh -p 2020 root@localhost

	
		Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-53-generic x86_64)
Last login: Wed Feb 22 15:12:07 2023 from 188.127.184.59
root@server2:~#

¡Conseguido! A través de mi ordenador no puedo conectarme directamente al server2, pero al conectarme al server3 he podido acceder al server2 gracias a la conexión inversa que había hecho del server2 al server3

Jump

Por último, otra manera de entrar al server2 es entrando al server1 y a continuación, desde el server1 entrar al server2. Pero esto es un poco engorroso, porque primero hay que hacer una conexión SSH al server1 y luego otra al server2, así que para hacerlo todo de una podemos usar el flag -J (jump), es decir, quedaría ssh -J server1 server2

Resumen, primero haríamos ssh root@194.62.99.222 y luego ssh root@10.7.2.228 (ya que dentro de server1 nos conectamos a server2 mediante la IP privada).

Así que podríamos hacer todo de una haciendo ssh -J root@194.62.99.222 root@10.7.2.228

Vamos a probar

	
		!ssh -J root@194.62.99.222 root@10.7.2.228

	
		Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-60-generic x86_64)
Last login: Fri Feb 24 06:46:11 2023 from 10.7.0.168
root@server2:~#

¡Hemos podido hacer los saltos!

Archivo de configuración `SSH` del usuario

Dispositivos con Alias

En todo ordenador hay un archivo de configuración para el SSH que suele estar en la carpeta del usuario

	
		!cat ~/.ssh/config

	
		# Read more about SSH config files: https://linux.die.net/man/5/ssh_config
Host 192.168.1.138
    HostName 192.168.1.138
    User maximo.fernandez

En este archivo tengo guardadas las credenciales de usuario e IP de algunos dispositivos a los que me suelo conectar y así no tengo que rellenar todo yo. Veámoslo con los servidores que tengo

Mi servidor server1 tiene el usuario root y la IP 194.62.99.222, por lo que lo añado a la lista

	
		!echo "Host server1
    HostName 194.62.99.222
    User root" &gt;&gt; ~/.ssh/config

Volvamos a ver cómo ha quedado el archivo de configuración

	
		!cat ~/.ssh/config

	
		# Read more about SSH config files: https://linux.die.net/man/5/ssh_config
Host 192.168.1.138
    HostName 192.168.1.138
    User maximo.fernandez
Host server1
    HostName 194.62.99.222
    User root

Ahora que lo hemos añadido para conectarnos al server1, ya solo nos hace falta hacer ssh server1

	
		!ssh server1

	
		Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-60-generic x86_64)
Last login: Fri Feb 24 05:18:59 2023 from 188.127.184.59
root@server1:~#

Proxy

Como ya vimos, añadiendo el flag -D &ltport&gt podíamos cambiar la proxy. Para dejar esto guardado en el archivo de configuración solo tenemos que añadir la línea DynamicForward &ltport&gt al host que estamos guardando

Repitiendo el ejemplo anterior en el que usamos el server1 como un proxy del puerto TCP/IP (9999), en el archivo de configuración quedaría así

Host proxyServer1
          HostName 194.62.99.222
          User root
          DynamicForward 9999

Lo añadimos

	
		!echo "Host proxyServer1
    HostName 194.62.99.222
    User root
    DynamicForward 9999" &gt;&gt; ~/.ssh/config

Veamos cómo queda el archivo de configuración

	
		!cat ~/.ssh/config

	
		# Read more about SSH config files: https://linux.die.net/man/5/ssh_config
Host 192.168.1.138
    HostName 192.168.1.138
    User maximo.fernandez
Host server1
    HostName 194.62.99.222
    User root
Host proxyServer1
    HostName 194.62.99.222
    User root
    DynamicForward 9999

Obtengo mi IP pública

	
		!curl ifconfig.me

	
		188.127.184.59

Me conecto al servidor proxy

	
		!ssh proxyServer1

	
		Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-60-generic x86_64)
Last login: Fri Feb 24 05:42:32 2023 from 188.127.184.59
root@server1:~#

Cambio la configuración del proxy de mi ordenador

Vuelvo a ver mi IP pública, pero usando el proxy recientemente configurado

	
		!curl -x socks5h://localhost:9999 ifconfig.me

	
		194.62.99.222

Vemos que obtenemos la IP pública del servidor

Tunel SSH

Si como antes quiero crear un túnel hasta el server2 a través del server1, antes teníamos que hacer ssh &ltHOST PORT&gt:&ltDEST IP&gt:&ltTUNNEL PORT&gt &ltTUNNEL CREATOR USER&gt@&ltTUNNEL CREATOR IP&gt, ahora tenemos que añadir la línea

LocalForward &ltlocalhost&gt:&ltHOST PORT&gt &ltDEST IP&gt:&ltTUNNEL PORT&gt

Es decir, el archivo de configuración quedaría

Host tunelToServer2
          HostName 194.62.99.222
          User root
          LocalForward 127.0.0.1:2020 10.7.2.228:22

Pero como así no se entiende muy bien veámoslo con algo concreto

server1:

IP pública: 194.62.99.222
IP privada: 10.7.0.168

server2:

IP pública: 194.62.99.235
IP privada: 10.7.2.228

Antes, el comando era

ssh -L 2020:10.7.2.228:22 root@194.62.99.222

De modo que el archivo de configuración tiene que quedar

Host tunelToServer2
          HostName 194.62.99.222
          User root
          LocalForward 127.0.0.1:2020 10.7.2.228:22

Veamos si funciona

Añadimos la nueva configuración

	
		!echo "Host tunelToServer2
    HostName 194.62.99.222
    User root
    LocalForward 127.0.0.1:2020 10.7.2.228:22" &gt;&gt; ~/.ssh/config

Veamos cómo ha quedado el archivo de configuración

	
		!cat ~/.ssh/config

	
		# Read more about SSH config files: https://linux.die.net/man/5/ssh_config
Host 192.168.1.138
    HostName 192.168.1.138
    User maximo.fernandez
Host server1
    HostName 194.62.99.222
    User root
Host proxyServer1
    HostName 194.62.99.222
    User root
    DynamicForward 9999
Host tunelToServer2
    HostName 194.62.99.222
    User root
    LocalForward 127.0.0.1:2020 10.7.2.228:22

Creamos el túnel

	
		!ssh tunelToServer2

	
		Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-60-generic x86_64)
Last login: Fri Feb 24 06:02:20 2023 from 188.127.184.59
root@server1:~#

Ahora intentamos conectarnos al server2 desde mi ordenador.

	
		!ssh -p 2020 root@localhost

	
		Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-60-generic x86_64)
Last login: Fri Feb 24 06:02:36 2023 from 10.7.0.168
root@server2:~#

¡Conseguido! Pero podemos dejarlo un poco más limpio todo, podemos añadir esta última conexión al archivo de configuración

	
		!echo "Host server2ByTunel
    HostName localhost
    User root
    Port 2020" &gt;&gt; ~/.ssh/config

Veamos cómo queda el archivo de configuración

	
		!cat ~/.ssh/config

	
		# Read more about SSH config files: https://linux.die.net/man/5/ssh_config
Host 192.168.1.138
    HostName 192.168.1.138
    User maximo.fernandez
Host server1
    HostName 194.62.99.222
    User root
Host proxyServer1
    HostName 194.62.99.222
    User root
    DynamicForward 9999
Host tunelToServer2
    HostName 194.62.99.222
    User root
    LocalForward 127.0.0.1:2020 10.7.2.228:22
Host server2ByTunel
    HostName localhost
    User root
    Port 2020

Ahora nos volvemos a conectar al server2 desde mi ordenador, a través del túnel, pero con la última configuración que acabamos de guardar

	
		!ssh server2ByTunel

	
		Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-60-generic x86_64)
Last login: Fri Feb 24 06:13:33 2023 from 10.7.0.168
root@server2:~#

En resumen, con todo lo que hemos hecho, podemos crear el túnel hasta el server2 con el comando ssh tunelToServer2 y a continuación conectarnos al server2 con el comando ssh server2ByTunel

¡Impresionante!

Conexión reversa

Recordamos que ahora nuestro problema era que no nos podíamos conectar al server2 a través del túnel del server1. De modo que creando una conexión reversa desde el server2 (tenemos alguien en el server2 que puede hacer esa conexión reversa, o lo dejamos hecho nosotros antes de irnos) hasta un server3, desde mi ordenador me puedo conectar al server3 y a continuación conectarme al server2

Primero tenemos que hacer la conexión reversa desde el server2 al server3. Esto lo podríamos hacer mediante un comando

ssh -R &ltserver3port&gt:localhost:22 root@&ltIPserver3&gt

O guardar la conexión en el archivo de configuración añadiendo

Host reverseToServer3
          HostName &ltIPserver3&gt
          User root
          RemoteForward &ltserver3port&gt localhost:22

Y hacer la conexión inversa mediante

ssh reverseToServer3

Como así no se entiende bien, veámoslo con datos concretos

server2:

IP pública: 194.62.99.235

server3:

IP pública: 194.62.96.236

Para hacer la conexión inversa habría que usar el comando

ssh -R 2020:localhost:22 root@194.62.96.236

o guardar la siguiente configuración

Host reverseToServer3
  HostName 194.62.96.236
  User root
  RemoteForward 2020 localhost:22

Y conectarse mediante

ssh reverseToServer3

De modo que guardo la configuración en el servidor 2 y hago la conexión

	
		!root@server2:~# echo "Host reverseToServer3
    HostName 194.62.96.236
    User root
    RemoteForward 2020 localhost:22" &gt;&gt; ~/.ssh/config

Veamos que se ha guardado bien

	
		!root@server2:~# cat .ssh/config

	
		Host reverseToServer3
    HostName 194.62.96.236
    User root
    RemoteForward 2020 localhost:22

Hago la conexión inversa

	
		!root@server2:~# ssh reverseToServer3

	
		Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-53-generic x86_64)
Last login: Wed Feb 22 15:26:18 2023 from 194.62.99.235
root@server3:~#

Jump

Como hemos dicho hacíamos saltos mediante el flag -J, de manera que con el comando ssh -J root@194.62.99.222 root@10.7.2.228 podíamos conectarnos al server2

Para configurar el archivo de configuración, hay dos opciones

La primera es que como ya tenemos el server1 guardado en el archivo de configuración, solamente añadimos server2

Host server2
  HostName 10.7.2.228
  User root

Y a continuación nos podríamos conectar mediante

ssh -J server1 server2

Vamos a probarlo

	
		!echo "Host server2
    HostName 10.7.2.228
    User root
" &gt;&gt; ~/.ssh/config

Vemos el archivo de configuración

	
		!cat ~/.ssh/config

	
		# Read more about SSH config files: https://linux.die.net/man/5/ssh_config
Host 192.168.1.138
    HostName 192.168.1.138
    User maximo.fernandez
Host server1
    HostName 194.62.99.222
    User root
Host proxyServer1
    HostName 194.62.99.222
    User root
    DynamicForward 9999
Host tunelToServer2
    HostName 194.62.99.222
    User root
    LocalForward 127.0.0.1:2020 10.7.2.228:22
Host server2ByTunel
    HostName localhost
    User root
    Port 2020
Host server2
    HostName 10.7.2.228
    User root

Ahora nos conectamos mediante los saltos

	
		!ssh -J server1 server2

	
		Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-60-generic x86_64)
Last login: Fri Feb 24 12:05:16 2023 from 10.7.0.168
root@server2:~#

Esta ha sido la primera opción: guardar cada servidor y establecer los saltos; pero una segunda opción es guardar todos los saltos en una sola configuración, que quedaría así

Host server2jumping
  HostName 10.7.2.228
  User root
  ProxyJump root@194.62.99.222

Y ya solo faltaría conectarse mediante

ssh server2jumping

Vamos a probar

	
		!echo "Host server2jumping
    HostName 10.7.2.228
    User root
    ProxyJump root@194.62.99.222" &gt;&gt; ~/.ssh/config

Vamos a ver el archivo de configuración

	
		!cat ~/.ssh/config

	
		# Read more about SSH config files: https://linux.die.net/man/5/ssh_config
Host 192.168.1.138
    HostName 192.168.1.138
    User maximo.fernandez
Host server1
    HostName 194.62.99.222
    User root
Host proxyServer1
    HostName 194.62.99.222
    User root
    DynamicForward 9999
Host tunelToServer2
    HostName 194.62.99.222
    User root
    LocalForward 127.0.0.1:2020 10.7.2.228:22
Host server2ByTunel
    HostName localhost
    User root
    Port 2020
Host server2
    HostName 10.7.2.228
    User root
Host server2jumping
    HostName 10.7.2.228
    User root
    ProxyJump root@194.62.99.222

Ahora intentamos conectarnos

	
		!ssh server2jumping

	
		Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-60-generic x86_64)
Last login: Fri Feb 24 12:06:22 2023 from 10.7.0.168
root@server2:~#

Archivo de configuración `SSH` del sistema

Antes vimos el archivo de configuración de SSH del usuario, donde guardamos configuraciones de máquinas donde nos queríamos conectar por SSH, pero hay otro archivo de configuración de SSH pero en este caso del sistema, que se encuentra en /etc/ssh/ssh_config, vamos a verlo

	
		!cat /etc/ssh/sshd_config

	
		#	$OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $
# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.
Include /etc/ssh/sshd_config.d/*.conf
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key
# Ciphers and keying
#RekeyLimit default none
# Logging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
#PubkeyAuthentication yes
# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile	.ssh/authorized_keys .ssh/authorized_keys2
#AuthorizedPrincipalsFile none
#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none
# no default banner path
#Banner none
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
# override default of no subsystems
Subsystem	sftp	/usr/lib/openssh/sftp-server
# Example of overriding settings on a per-user basis
#Match User anoncvs
#	X11Forwarding no
#	AllowTcpForwarding no
#	PermitTTY no
#	ForceCommand cvs server

Con este archivo podemos cambiar la configuración de cómo funciona SSH en nuestro ordenador. Por ejemplo, podemos ver una línea comentada que pone

#Port 22

Si la descomentamos y cambiamos el número SSH dejará de ir por el puerto 22, que es su puerto por defecto, e irá por el número de puerto que ahí se especifique.

Copia de archivos por `SSH`

Podemos copiar archivos por SSH mediante el comando scp (secure copy). Para ello, la sintaxis es

scp &ltpath local file&gt &ltuser&gt@&ltIP&gt:&ltpath to save&gt

scp &ltuser&gt@&ltip&gt:&ltpath to remote file&gt &ltpath to save&gt

De la primera forma se copia un archivo de nuestro ordenador a otro y, de la segunda, de otro al nuestro

Por ejemplo, hagamos un ls del server1

	
		!ssh -t server1 "ls"

	
		snap
Connection to 194.62.99.222 closed.

Veamos ahora qué tenemos en local que le podamos pasar

!ls

	
		2021-02-11-Introduccion-a-Python.ipynb         html_files
2021-04-23-Calculo-matricial-con-Numpy.ipynb   html.ipynb
2021-06-15-Manejo-de-datos-con-Pandas.ipynb    introduccion_python
2022-09-12-Introduccion-a-la-terminal.ipynb    mi_paquete_de_python
2023-01-22-Docker.ipynb		        movies.csv
2023-02-01-Bash-scripting.ipynb	        movies.dat
2023-02-04-Blip-2.ipynb		        notebooks_translated
2023-XX-XX-SSH.ipynb			        __pycache__
california_housing_train.csv		        scripts_bash
command-line-cheat-sheet.pdf		        ssh.ipynb
CSS.ipynb				        test.ipynb
'Expresiones regulares.ipynb'

Vamos a enviar al servidor el archivo html.ipynb ya que ocupa poco

	
		!scp html.ipynb server1:/root/

	
		html.ipynb                                    100%   14KB 229.0KB/s   00:00

Volvemos a ver qué hay dentro de server1

	
		!ssh -t server1 "ls"

	
		html.ipynb  snap
Connection to 194.62.99.222 closed.

Se ha copiado

Sincroniazción de archivos por `SSH`

Lo malo del comando scp es que si en medio de la copia pasa algo y no se termina de copiar el archivo, cuando se vuelva a intentar hay que empezar desde cero, esto sobre todo es un problema con archivos muy grandes

Para solucionar esto se puede usar rsync, la sintaxis es

rsync --partial --progress --rsh=ssh <path local file> <user>@<IP>:<path to save>

rsync --partial --progress --rsh=ssh <user>@<ip>:<path to remote file> <path to save>

Al igual que antes, de la primera forma se copia un archivo de nuestro ordenador a otro y de la segunda de otro al nuestro. El flag --partial es para indicar que se guarden archivos parcialmente copiados, es decir, que si se para la copia antes de que termine, lo que se haya copiado se mantenga. El flag --progress es para indicar que muestre el progreso de la copia. El flag --rsh=ssh es para indicar que la transferencia de archivos se haga por SSH

Pasamos un archivo

	
		!rsync --partial --progress -rsh=ssh 2021-06-15-Manejo-de-datos-con-Pandas.ipynb server1:/root/

	
		sending incremental file list
2021-06-15-Manejo-de-datos-con-Pandas.ipynb
        608.34K 100%  197.78MB/s    0:00:00 (xfr#1, to-chk=0/1)

Y vemos si se ha copiado

	
		!ssh -t server1 "ls"

	
		2021-06-15-Manejo-de-datos-con-Pandas.ipynb  html.ipynb  snap
Connection to 194.62.99.222 closed.

Montar carpetas remotas en local

En el caso que queramos tener una carpeta de otra máquina como si estuviese en nuestro ordenador tenemos que usar sshfs

Primero es necesario instalarlo mediante

sudo apt install sshfs

Y una vez esté instalado, se usa con la sintaxis

sshfs &ltuser&gt@&ltip&gt:&ltremote path&gt &ltlocal path to mount&gt

Vamos a montar la carpeta /root del server1, pero para ello primero vamos a crear una carpeta en la que lo vamos a montar

	
		!mkdir server1folder

Vemos que, dentro de la carpeta que hemos montado, no hay nada

	
		!ls server1folder

Ahora montamos la carpeta del servidor

	
		!!sshfs server1:/root/ server1folder

Volvemos a ver qué hay dentro

	
		!ls server1folder

	
		2021-06-15-Manejo-de-datos-con-Pandas.ipynb  html.ipynb  snap

Cuando ya no queramos tener más la carpeta montada, la podemos desmontar mediante fusermount -u server1folder

	
		!!fusermount -u server1folder

Volvemos a mirar qué hay dentro para ver si no hay nada

	
		!ls server1folder

Depurar la conexión `SSH`

Podemos depurar la conexión SSH añadiendo desde -v, hasta -vvvv a la conexión, cuantas más vs pongamos, mayor nivel de información

	
		!ssh -v server1

	
		OpenSSH_8.2p1 Ubuntu-4ubuntu0.5, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /home/wallabot/.ssh/config
debug1: /home/wallabot/.ssh/config line 6: Applying options for server1
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 194.62.99.222 [194.62.99.222] port 22.
debug1: Connection established.
debug1: identity file /home/wallabot/.ssh/id_rsa type 0
debug1: identity file /home/wallabot/.ssh/id_rsa-cert type -1
debug1: identity file /home/wallabot/.ssh/id_dsa type -1
debug1: identity file /home/wallabot/.ssh/id_dsa-cert type -1
debug1: identity file /home/wallabot/.ssh/id_ecdsa type -1
debug1: identity file /home/wallabot/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/wallabot/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/wallabot/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/wallabot/.ssh/id_ed25519 type -1
debug1: identity file /home/wallabot/.ssh/id_ed25519-cert type -1
debug1: identity file /home/wallabot/.ssh/id_ed25519_sk type -1
debug1: identity file /home/wallabot/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/wallabot/.ssh/id_xmss type -1
debug1: identity file /home/wallabot/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.9p1 Ubuntu-3
debug1: match: OpenSSH_8.9p1 Ubuntu-3 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 194.62.99.222:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server-&gt;client cipher: chacha20-poly1305@openssh.com MAC: &lt;implicit&gt; compression: none
debug1: kex: client-&gt;server cipher: chacha20-poly1305@openssh.com MAC: &lt;implicit&gt; compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:jwpQt2a69LQcuvvYPPKL32bBwTi1Je/ZmUdr4zEiD1Y
debug1: Host '194.62.99.222' is known and matches the ECDSA host key.
debug1: Found key in /home/wallabot/.ssh/known_hosts:14
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/wallabot/.ssh/id_rsa RSA SHA256:ID3HcrbyPBGjFx/qeiJK50eqihLGrpDVu02oRSyKGh4 agent
debug1: Will attempt key: wallabot@wallabot RSA SHA256:Qlq6hXbToInW+efEK666BFT26EeUSpBhzcqxTLrDBpQ agent
debug1: Will attempt key: /home/wallabot/.ssh/id_dsa
debug1: Will attempt key: /home/wallabot/.ssh/id_ecdsa
debug1: Will attempt key: /home/wallabot/.ssh/id_ecdsa_sk
debug1: Will attempt key: /home/wallabot/.ssh/id_ed25519
debug1: Will attempt key: /home/wallabot/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/wallabot/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=&lt;ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com&gt;
debug1: kex_input_ext_info: publickey-hostbound@openssh.com (unrecognised)
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/wallabot/.ssh/id_rsa RSA SHA256:ID3HcrbyPBGjFx/qeiJK50eqihLGrpDVu02oRSyKGh4 agent
debug1: Authentications that can continue: publickey
debug1: Offering public key: wallabot@wallabot RSA SHA256:Qlq6hXbToInW+efEK666BFT26EeUSpBhzcqxTLrDBpQ agent
debug1: Server accepts key: wallabot@wallabot RSA SHA256:Qlq6hXbToInW+efEK666BFT26EeUSpBhzcqxTLrDBpQ agent
debug1: Authentication succeeded (publickey).
Authenticated to 194.62.99.222 ([194.62.99.222]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: /root/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /root/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Sending environment.
debug1: Sending env LANG = es_ES.UTF-8
Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-60-generic x86_64)
* Documentation:  https://help.ubuntu.com
* Management:     https://landscape.canonical.com
* Support:        https://ubuntu.com/advantage
  System information as of Fri Feb 24 01:25:10 PM UTC 2023
  System load:           0.0
  Usage of /:            15.2% of 24.53GB
  Memory usage:          34%
  Swap usage:            0%
  Processes:             89
  Users logged in:       0
  IPv4 address for eth0: 194.62.99.222
  IPv4 address for eth1: 10.7.0.168
  IPv6 address for eth2: 2a04:3542:8000:1000:d48a:cbff:fefb:5b1
* Strictly confined Kubernetes makes edge and IoT secure. Learn how MicroK8s
   just raised the bar for easy, resilient and secure K8s cluster deployment.
   https://ubuntu.com/engage/secure-kubernetes-at-the-edge
43 updates can be applied immediately.
To see these additional updates run: apt list --upgradable
Last login: Fri Feb 24 13:10:05 2023 from 188.127.184.59
]0;root@server1: ~root@server1:~# ^C
]0;root@server1: ~root@server1:~#

Seguir leyendo

Patrones de agentes

¿Tus agentes se quedan cortos? Eleva tus proyectos de IA con patrones avanzados: ReAct, planificación, multi-agentes y más. ¡Guía práctica con código!

LangGraph: Revolución en tus agentes de IA

🚀 ¡Revoluciona tus agentes de IA! 🧠 LangGraph no es solo otra librería, es el framework de orquestación que te da el CONTROL total para construir agentes complejos, con memoria a largo plazo y ¡hasta con intervención humana! Olvídate de los chatbots básicos, es hora de crear verdadera inteligencia. ¡Sumérgete en este post y descúbrelo!

Crear entornos virtuales con uv

Aprende a crear entornos virtuales con uv, un gestor de paquetes y entornos para Python escrito en Rust, lo que hace que vaya rapidísimo. Si has tenido problemas con los tiempos de espera usando conda, o quieres una alternativa más rápida y fácil a venv, entra y mira cómo usar uv.

Últimos posts -->

¿Has visto estos proyectos?

Horeca chatbot

Naviground

Subtify

Ver todos los proyectos -->

¿Quieres aplicar la IA en tu proyecto? Contactame!

¿Quieres mejorar con estos tips?

Memory profiler

Ver el uso de memoria de un script

DataLoader con pin_memory y num_workers

Aumentar el rendimiento de DataLoader con pin_memory y num_workers

py-smi

Librería de Python para obtener datos de la GPU igual que `nvidia-smi`

Últimos tips -->

Usa esto en local

Los espacios de Hugging Face nos permite ejecutar modelos con demos muy sencillas, pero ¿qué pasa si la demo se rompe? O si el usuario la elimina? Por ello he creado contenedores docker con algunos espacios interesantes, para poder usarlos de manera local, pase lo que pase. De hecho, es posible que si pinchas en alún botón de ver proyecto te lleve a un espacio que no funciona.

Flow edit

FLUX.1-RealismLora

token_hmr

Ver todos los contenedores -->

¿Quieres aplicar la IA en tu proyecto? Contactame!

¿Quieres entrenar tu modelo con estos datasets?

short-jokes-dataset

Dataset de chistes en inglés

opus100

Dataset con traducciones de inglés a español

netflix_titles

Dataset con películas y series de Netflix

Ver más datasets -->

Introducción histórica

Cifrado de SSH

Requerimentos SSH

Servicio SSH

Cliente SSH

Conexión por SSH

Conexión sin necesidad de contraseña

Usar la terminal remota por SSH

Proxy SSH

Interfaz gráfica remota por SSH

Tunel SSH

Conexión reversa

Jump

Archivo de configuración SSH del usuario

Dispositivos con Alias

Proxy

Tunel SSH

Conexión reversa

Jump

Archivo de configuración SSH del sistema

Copia de archivos por SSH

Sincroniazción de archivos por SSH

Montar carpetas remotas en local

Depurar la conexión SSH

Seguir leyendo

Patrones de agentes

LangGraph: Revolución en tus agentes de IA

Crear entornos virtuales con uv

¿Has visto estos proyectos?

¿Quieres aplicar la IA en tu proyecto? Contactame!

¿Quieres mejorar con estos tips?

Memory profiler

DataLoader con pin_memory y num_workers

py-smi

Usa esto en local

¿Quieres aplicar la IA en tu proyecto? Contactame!

¿Quieres entrenar tu modelo con estos datasets?

short-jokes-dataset

opus100

netflix_titles

Cifrado de `SSH`

Requerimentos `SSH`

Servicio `SSH`

Cliente `SSH`

Conexión por `SSH`

Usar la terminal remota por `SSH`

Proxy `SSH`

Interfaz gráfica remota por `SSH`

Tunel `SSH`

Archivo de configuración `SSH` del usuario

Archivo de configuración `SSH` del sistema

Copia de archivos por `SSH`

Sincroniazción de archivos por `SSH`

Depurar la conexión `SSH`