La red desde la terminal

1. Cinco conceptos de red

Este no es un curso de redes, y no hace falta que lo sea. Para usar los comandos del tema alcanza con cinco ideas, que son las que aparecen en sus salidas y en sus mensajes de error.

Una comunicación completa se describe con esos datos: «desde mi interfaz, con mi dirección, a través de la puerta de enlace, hasta la dirección que el DNS dio para ese nombre, en tal puerto». Cuando la red no funciona, uno de esos eslabones está roto, y el diagnóstico consiste en probarlos en orden.

Las direcciones del ejemplo son las tradicionales, de la versión 4 del protocolo: cuatro números de 0 a 255 separados por puntos. Algunos rangos tienen un significado fijo, y reconocerlos ahorra confusiones:

De ahí sale una distinción que se necesita apenas se quiere llegar a una máquina desde afuera. Tu equipo tiene una dirección privada, que le dio el router; hacia Internet, toda la casa sale con una sola dirección pública, la del router. Son dos números distintos, y cada uno se averigua de una manera. Las direcciones de la versión 6, como fe80::a2c5:89ff:fe3b:71d2, conviven con las anteriores y aparecerán en las salidas; lo dicho vale igual para ellas.

2. ip address: interfaces y direcciones

ip es el comando para consultar y configurar la red. Es de los que llevan subcomandos, como anticipamos en el tema 3: ip address trata de direcciones, ip route, de rutas. Los subcomandos se pueden abreviar, y casi todo el mundo escribe ip a e ip r. Consultar no requiere sudo.

$ ip -br address
lo               UNKNOWN        127.0.0.1/8 ::1/128
enp0s31f6        DOWN
wlp3s0           UP             192.168.1.37/24 fe80::a2c5:89ff:fe3b:71d2/64

La opción -br, de brief, da una línea por interfaz: nombre, estado y direcciones. Este equipo tiene tres.

Los nombres parecen arbitrarios y no lo son. Las dos primeras letras indican la clase —en para Ethernet, wl para inalámbrica— y el resto, la posición física de la placa en el equipo, de modo que el nombre no cambia de un arranque a otro. wlp3s0 es la placa del bus 3, la misma que lspci mostraba en 03:00.0 en el tema 37. En máquinas virtuales y sistemas más viejos aparecen los nombres clásicos, eth0 y wlan0.

Sin -br, la salida es completa. Pidiendo una sola interfaz:

$ ip address show wlp3s0
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether a0:c5:89:3b:71:d2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.37/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp3s0
       valid_lft 82014sec preferred_lft 82014sec
    inet6 fe80::a2c5:89ff:fe3b:71d2/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

Para obtener solo el número, sin nada que filtrar, hay un atajo: hostname -I escribe las direcciones de la máquina, separadas por espacios. Y la dirección pública, la que ven los servidores de Internet, no figura en ninguna interfaz: es del router. Se la pregunta a un servicio externo, con el curl de la sección 8.

$ hostname -I
192.168.1.37
$ curl -s ifconfig.me; echo
203.0.113.45

En los tutoriales anteriores a 2015 el comando para todo esto es ifconfig. Pertenece a un paquete, net-tools, que las distribuciones ya no instalan, junto con route y netstat. Sus reemplazos son los de este tema: ip address, ip route y ss.

3. ip route: por dónde se sale

Tener dirección no alcanza para llegar a Internet: hay que saber a quién entregarle lo que va hacia afuera. Eso lo dice la tabla de rutas.

$ ip route
default via 192.168.1.1 dev wlp3s0 proto dhcp src 192.168.1.37 metric 600
192.168.1.0/24 dev wlp3s0 proto kernel scope link src 192.168.1.37 metric 600

Dos líneas, que se leen de abajo hacia arriba. La segunda dice que la red 192.168.1.0/24 está directamente conectada a wlp3s0: a los equipos de la casa se les habla sin intermediarios. La primera es la ruta por defecto: todo lo que no sea de esa red se envía a 192.168.1.1, la puerta de enlace. Ese es el dato que se busca aquí.

Si no hay una línea default, la máquina puede hablar con sus vecinas y con nadie más: es la explicación de «tengo red local y no tengo Internet». Para saber qué camino tomaría un destino concreto:

$ ip route get 1.1.1.1
1.1.1.1 via 192.168.1.1 dev wlp3s0 src 192.168.1.37 uid 1000
$ ip route get 192.168.1.50
192.168.1.50 dev wlp3s0 src 192.168.1.37 uid 1000

Hacia Internet, pasando por el router; hacia un equipo de la red local, directamente. Con varias interfaces activas —cable e inalámbrica, o una red privada virtual—, esta consulta dice sin lugar a dudas por cuál sale cada cosa.

4. Nombres y DNS

Nadie recuerda direcciones. Se escribe un nombre, y el sistema lo traduce antes de conectarse. La traducción consulta dos fuentes, en este orden:

$ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 equipo
…
$ host www.gnu.org
www.gnu.org is an alias for wildebeest1p.gnu.org.
wildebeest1p.gnu.org has address 209.51.188.116
wildebeest1p.gnu.org has IPv6 address 2001:470:142:5::116
$ host no-existe.example
Host no-existe.example not found: 3(NXDOMAIN)

/etc/hosts es el archivo que conocimos en el tema 8, y explica por qué localhost y el nombre de la propia máquina funcionan sin red. Agregarle una línea —192.168.1.50 servidor— permite llamar por su nombre a un equipo de la red local que ningún DNS conoce. host hace una consulta al DNS y muestra la respuesta; NXDOMAIN es la manera en que el DNS dice «ese nombre no existe».

$ resolvectl status wlp3s0 | grep -i 'dns server'
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1
$ cat /etc/resolv.conf | grep -v '^#'
nameserver 127.0.0.53
options edns0 trust-ad
search .

El archivo tradicional que indica el servidor DNS es /etc/resolv.conf. En Ubuntu apunta a 127.0.0.53, una dirección de la propia máquina: allí escucha un servicio, systemd-resolved, que recibe todas las consultas, las reenvía al servidor verdadero y recuerda las respuestas. Por eso la pregunta «¿qué DNS estoy usando?» se le hace a resolvectl, y no al archivo.

El DNS es responsable de una gran parte de las fallas que se describen como «no anda Internet». La manera de distinguirlo es la de la sección 6: si se llega a un destino por su número y no por su nombre, la red funciona, y lo roto es la traducción.

5. ping: ¿responde?

ping envía a un destino un mensaje mínimo que pide respuesta, y mide cuánto tarda en volver. Es la prueba elemental de conectividad, y lo usamos sin explicarlo en el tema 25.

$ ping -c 4 www.gnu.org
PING wildebeest1p.gnu.org (209.51.188.116) 56(84) bytes of data.
64 bytes from wildebeest1p.gnu.org (209.51.188.116): icmp_seq=1 ttl=52 time=168 ms
64 bytes from wildebeest1p.gnu.org (209.51.188.116): icmp_seq=2 ttl=52 time=171 ms
64 bytes from wildebeest1p.gnu.org (209.51.188.116): icmp_seq=3 ttl=52 time=167 ms
64 bytes from wildebeest1p.gnu.org (209.51.188.116): icmp_seq=4 ttl=52 time=169 ms

--- wildebeest1p.gnu.org ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 167.212/168.790/171.034/1.498 ms

En Linux, ping no se detiene solo: sin -c sigue enviando hasta que se lo interrumpe con Ctrl+C, y recién entonces muestra las estadísticas. Quien viene de Windows, donde hace cuatro envíos y termina, cree que el comando se colgó.

El código de salida es 0 si hubo al menos una respuesta, y por eso sirve en una condición, como en la receta de entonces: ping -c 1 -W 2 servidor > /dev/null && echo "responde" || echo "no responde".

Cuando falla, el mensaje indica en qué eslabón:

Para ver el camino completo, salto por salto, están tracepath destino, que viene instalado, y traceroute y mtr, que se instalan aparte. Muestran cada equipo intermedio y su tiempo de respuesta, y señalan dónde se corta una comunicación que no llega.

6. Diagnosticar por capas

«No tengo Internet» es un síntoma con cinco causas posibles, una por cada concepto de la sección 1. Se las descarta en orden, de lo más cercano a lo más lejano, y la primera prueba que falla señala el eslabón roto.

1. ¿Hay interfaz con dirección? ip -br address. Si está DOWN o sin dirección, el problema es el cable, la red inalámbrica o el DHCP. interfaz
2. ¿Hay ruta por defecto? ip route. Anotar la dirección de la puerta de enlace. ruta
3. ¿Responde la puerta de enlace? ping -c 3 192.168.1.1. Si no, falla la red local o el router. red local
4. ¿Se llega a Internet por número? ping -c 3 1.1.1.1. Si no, el router no tiene salida: es un problema del proveedor. salida
5. ¿Se llega por nombre? ping -c 3 www.gnu.org. Si el paso anterior funcionó y este no, falla el DNS. nombres

La dirección 1.1.1.1 es la de un servicio público de DNS, elegida por fácil de recordar y porque responde siempre; 8.8.8.8 cumple la misma función. Lo que hace valioso al procedimiento es que no adivina. En dos minutos se pasa de «no anda» a «la máquina está bien, la red local está bien, el router no tiene salida», que es una frase con la que se puede llamar al proveedor.

Si los cinco pasos funcionan y un servicio en particular no responde, la red está sana: el problema es de ese servicio, o de un puerto.

7. ss: puertos y conexiones

Un servicio de red escucha en un puerto: le pide al kernel que le entregue todo lo que llegue con ese número. Un programa que quiere usarlo se conecta a la dirección de la máquina y a ese puerto.

Los servicios conocidos tienen su puerto asignado por convención, de modo que no hace falta indicarlo:

La lista completa está en un archivo de texto, /etc/services, que se consulta con grep. Los puertos menores que 1024 están reservados: solo root puede poner un programa a escuchar en ellos.

ss, de socket statistics, muestra los puertos en uso. Se lo acompaña casi siempre con las mismas cuatro letras:

ss -tuln
    ││││
    │││└─ n: mostrar números, sin traducirlos a nombres
    ││└─ l: solo los que están escuchando (listening)
    │└─ u: los del protocolo UDP
    └─ t: los del protocolo TCP

$ ss -tuln
Netid State  Recv-Q Send-Q  Local Address:Port   Peer Address:Port Process
udp   UNCONN 0      0       127.0.0.53%lo:53          0.0.0.0:*
udp   UNCONN 0      0             0.0.0.0:5353        0.0.0.0:*
tcp   LISTEN 0      4096    127.0.0.53%lo:53          0.0.0.0:*
tcp   LISTEN 0      4096        127.0.0.1:631         0.0.0.0:*
tcp   LISTEN 0      4096                *:22                *:*

La columna que hay que leer con cuidado es Local Address:Port. El puerto dice qué servicio es; la dirección, desde dónde se lo puede alcanzar:

Esa diferencia explica el caso más frecuente con servicios propios: «instalé la base de datos, funciona en el servidor y desde mi máquina no me puedo conectar». Casi siempre escucha en 127.0.0.1, que es la configuración prudente de fábrica.

Para saber qué programa tiene cada puerto se agrega -p, que requiere sudo para ver los procesos ajenos:

$ sudo ss -tlnp
State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0      4096   127.0.0.53%lo:53        0.0.0.0:*     users:(("systemd-resolve",pid=612,fd=15))
LISTEN 0      4096       127.0.0.1:631       0.0.0.0:*     users:(("cupsd",pid=1033,fd=7))
LISTEN 0      4096               *:22              *:*     users:(("sshd",pid=8410,fd=3),("systemd",pid=1,fd=160))
$ sudo ss -tlnp | grep ':631 '          # ¿quién tiene el puerto 631?

Cada línea termina con el nombre y el PID del proceso, con lo que se vuelve al terreno de los temas 32 y 39. En el puerto 22 figuran dos: sshd y el propio systemd, que mantiene abierto el puerto y despierta al servicio cuando llega alguien. Es la unidad ssh.socket que mencionamos en el tema 39.

ss mira la propia máquina. Para probar un puerto de otra hay que intentar conectarse, y la herramienta mínima es nc, de netcat:

$ nc -zv 192.168.1.50 22
Connection to 192.168.1.50 22 port [tcp/ssh] succeeded!
$ nc -zv 192.168.1.50 80
nc: connect to 192.168.1.50 port 80 (tcp) failed: Connection refused
$ nc -zv -w 3 192.168.1.50 3306
nc: connect to 192.168.1.50 port 3306 (tcp) timed out: Operation now in progress

La opción -z prueba la conexión sin enviar nada, -v informa el resultado y -w fija cuánto esperar. Las dos formas de fallar dicen cosas distintas, y distinguirlas es media solución:

8. curl: hablar con un servidor

curl transfiere datos desde una dirección de Internet, o hacia ella. Su uso principal es el que haría un navegador sin pantalla: pedirle algo a un servidor web y entregar la respuesta. Si falta, se instala con sudo apt install curl.

$ cd ~/practica
$ curl https://www.gnu.org/licenses/gpl-3.0.txt | head -n 3
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 35149  100 35149    0     0  71402      0 --:--:-- --:--:-- --:--:-- 71440
                    GNU GENERAL PUBLIC LICENSE
                       Version 3, 29 June 2007

$ curl -s https://www.gnu.org/licenses/gpl-3.0.txt | wc -l
674

El comportamiento por defecto es el que lo hace encajar en este curso: curl escribe lo descargado en la salida estándar. No guarda nada. El contenido de una dirección web pasa a ser texto que entra en una tubería, igual que el de un archivo con cat. La tabla de progreso va por el canal de errores, por eso no se mezcla con los datos, y -s la suprime.

Con esa tabla se puede leer, por fin, la línea que criticamos en el tema 36, curl -fsSL https://… | sudo bash: «descargar, fallando ante un error del servidor, en silencio pero mostrando los errores, siguiendo las redirecciones», y entregar el resultado a una shell con privilegios. Las cuatro letras son la forma estándar de usar curl en un script; lo objetable era lo que venía después de la barra.

Los encabezados y el código de estado

Todo servidor web antepone a su respuesta unas líneas que la describen. La primera lleva un número de tres cifras, el código de estado, que dice cómo le fue al pedido:

$ curl -sI https://www.gnu.org/licenses/gpl-3.0.txt
HTTP/1.1 200 OK
Date: Tue, 13 Oct 2026 15:02:11 GMT
Server: Apache/2.4.29
Content-Length: 35149
Content-Type: text/plain
…
$ curl -s -o /dev/null -w '%{http_code}\n' https://www.gnu.org/no-existe
404

La primera cifra da la clase: 2 es éxito, 3 redirección, 4 un error de quien pide, 5 un error de quien responde. La segunda forma del ejemplo, con -w, descarta el contenido y escribe solo el código: es la manera de verificar desde un script que un sitio está en pie. Y es la respuesta a la advertencia de la sección 5: un servidor web no se comprueba con ping, sino pidiéndole una página.

curl sirve además para conversar con los servicios que entregan datos en lugar de páginas, las API. Responden texto, por lo general en formato JSON, que se procesa con una herramienta dedicada, jq. Es el camino por el que un script consulta el clima, una cotización o el estado de un servidor.

9. wget: descargar archivos

wget hace una sola cosa, y está pensado para hacerla sin vigilancia: descargar archivos. A diferencia de curl, guarda en el disco sin que se lo pidan, sigue las redirecciones y reintenta si la conexión se corta.

$ wget https://www.gnu.org/licenses/gpl-3.0.txt
--2026-10-13 12:10:02--  https://www.gnu.org/licenses/gpl-3.0.txt
Resolving www.gnu.org (www.gnu.org)... 209.51.188.116, 2001:470:142:5::116
Connecting to www.gnu.org (www.gnu.org)|209.51.188.116|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 35149 (34K) [text/plain]
Saving to: ‘gpl-3.0.txt’

gpl-3.0.txt         100%[===================>]  34.33K  --.-KB/s    in 0.05s

2026-10-13 12:10:03 (702 KB/s) - ‘gpl-3.0.txt’ saved [35149/35149]
$ wc -l gpl-3.0.txt
674 gpl-3.0.txt

La salida de wget es todo el tema en cuatro líneas: resolver el nombre con el DNS, conectarse a la dirección en el puerto 443, enviar el pedido y recibir el código 200. Cuando una descarga falla, la línea en que se detiene dice en qué eslabón: si no pasa de Resolving, es el DNS; si se queda en Connecting, la red o un cortafuegos; si responde 404, la dirección.

Si el archivo ya existe, wget no lo pisa: guarda el nuevo como gpl-3.0.txt.1. Para una descarga grande —una imagen .iso, por ejemplo— la opción que vale es -c: si se corta a los 3 GB, repetir el mismo comando retoma en lugar de empezar de nuevo. Y para dejarla corriendo aunque se cierre la terminal están el nohup y el & del tema 33.

Lo descargado de Internet conviene verificarlo. Los sitios serios publican, junto a cada archivo, su suma de verificación: una cadena calculada a partir del contenido, que cambia por completo si se altera un solo byte. sha256sum archivo la calcula para lo que llegó, y si coincide con la publicada, el archivo está íntegro.

10. ssh: una terminal en otra máquina

ssh, de secure shell, abre una sesión de terminal en otra máquina a través de la red. Todo lo que se escribe y todo lo que se recibe viaja cifrado. Lo que se ejecuta, se ejecuta allá: con los archivos, los programas y los recursos de la máquina remota.

Hacen falta dos cosas: que la máquina remota tenga en marcha el servidor de ssh, que escucha en el puerto 22, y tener en ella una cuenta de usuario. La forma del comando es la de una dirección de correo:

ssh ana@192.168.1.50
     │       │
     │       └─ la máquina: una dirección IP o un nombre
     └─ el usuario EN ESA MÁQUINA. Si se omite, se usa el nombre del usuario local

ana@equipo:~$ ssh ana@192.168.1.50
The authenticity of host '192.168.1.50 (192.168.1.50)' can't be established.
ED25519 key fingerprint is SHA256:Xk3v0q1mB7yT2dNf8sLwQ4hZr6uJc9aEoPiV5gYtR1U.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.1.50' (ED25519) to the list of known hosts.
ana@192.168.1.50's password:
Welcome to Ubuntu 24.04.3 LTS (GNU/Linux 6.8.0-87-generic x86_64)
…
ana@servidor:~$ hostname
servidor
ana@servidor:~$ uptime
 12:18:40 up 41 days,  3:07,  1 user,  load average: 0,08, 0,05, 0,01
ana@servidor:~$ exit
logout
Connection to 192.168.1.50 closed.
ana@equipo:~$ 

La contraseña que se pide es la de la cuenta en la máquina remota, y al escribirla no aparece nada, como con sudo en el tema 2. Una vez dentro, el indicador cambia: ana@servidor. Es la única señal de dónde se está, y la razón por la que el tema 34 insistió en conservar el nombre de la máquina en PS1. Todo lo que se escriba ahora ocurre en el servidor, hasta salir con exit o Ctrl+D.

Lo demás es lo de siempre. Los cuarenta temas anteriores funcionan igual a través de ssh, porque del otro lado hay una shell Bash. Esa es la recompensa de haber aprendido la terminal: un servidor a diez mil kilómetros se maneja exactamente como el equipo propio.

La pregunta de la primera vez

Antes de la contraseña hubo una pregunta. Cada servidor tiene una clave que lo identifica, y ssh muestra su huella, una versión corta de esa clave. La primera vez no tiene con qué compararla, y pregunta si se confía. Al responder yes —la palabra completa—, la anota en ~/.ssh/known_hosts, y en adelante la comprueba en silencio.

Ejecutar un solo comando

Si después de la dirección se escribe un comando, ssh lo ejecuta en la máquina remota, muestra su salida y termina, sin abrir una sesión:

ana@equipo:~$ ssh ana@192.168.1.50 'df -h / | tail -n 1'
/dev/sda2        98G   71G   23G  76% /
ana@equipo:~$ ssh ana@192.168.1.50 'journalctl -p err -b --no-pager' | wc -l
12
ana@equipo:~$ ssh ana@192.168.1.50 'cat /var/log/syslog' | grep -c cron
88

Las comillas simples deciden dónde se ejecuta cada parte. En la primera línea, toda la tubería está entre comillas y corre en el servidor. En la segunda, journalctl corre allá y wc, aquí: la salida del comando remoto atraviesa la red y entra en una tubería local. Es el mecanismo del tema 24, sin modificaciones, extendido a dos máquinas. También las variables y los comodines siguen las reglas del tema 9: sin comillas, los expande la shell local antes de que ssh arranque.

Una sesión de ssh depende de la conexión. Si la red se corta, la sesión muere, y con ella lo que estuviera ejecutándose: es el SIGHUP del tema 33. Para los trabajos largos en un servidor se usa tmux, que mantiene la sesión viva del lado remoto, como anticipamos entonces.

11. Claves en lugar de contraseñas

Escribir la contraseña en cada conexión es incómodo, y una contraseña es además lo que prueban sin descanso los programas que recorren Internet buscando servidores. La forma habitual de identificarse ante ssh es otra.

Un par de claves son dos archivos relacionados matemáticamente. La clave privada queda en tu máquina y no se entrega a nadie. La clave pública se copia a cada servidor al que quieras entrar. El servidor puede comprobar, con la pública, que quien se conecta tiene la privada, sin que esta viaje nunca por la red.

Son tres pasos, y los dos primeros se hacen una sola vez.

ana@equipo:~$ ssh-keygen -t ed25519 -C "ana@equipo"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/ana/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/ana/.ssh/id_ed25519
Your public key has been saved in /home/ana/.ssh/id_ed25519.pub
ana@equipo:~$ ls -l ~/.ssh
-rw------- 1 ana ana  411 oct 13 12:31 id_ed25519
-rw-r--r-- 1 ana ana   92 oct 13 12:31 id_ed25519.pub
-rw------- 1 ana ana  978 oct 13 12:18 known_hosts

-t ed25519 elige el tipo de clave, el recomendado hoy; -C le agrega un comentario para reconocerla. A la primera pregunta se responde con Enter, para aceptar el lugar habitual. La segunda pide una frase de paso: una contraseña que protege el archivo de la clave privada, de modo que quien lo robe no pueda usarlo. Conviene ponerla. Un programa, ssh-agent, que los escritorios ya traen en marcha, la recuerda durante la sesión para no pedirla en cada conexión.

Los permisos de los archivos no son casuales: la privada es rw-------, solo del dueño, y el directorio ~/.ssh, drwx------, como anotamos en la tabla del tema 17.

ana@equipo:~$ ssh-copy-id ana@192.168.1.50
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
ana@192.168.1.50's password:

Number of key(s) added: 1

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

ana@equipo:~$ ssh ana@192.168.1.50
Welcome to Ubuntu 24.04.3 LTS (GNU/Linux 6.8.0-87-generic x86_64)
ana@servidor:~$ cat ~/.ssh/authorized_keys
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGq7…Yw0x ana@equipo

La contraseña se pidió por última vez en el paso 2. ssh-copy-id agregó una línea al archivo ~/.ssh/authorized_keys de la cuenta remota, y esa línea es la clave pública entera: un texto de una sola línea, que también se podría haber pegado a mano. Es lo que piden los servicios en la nube y los sitios como GitHub cuando solicitan «tu clave SSH»: el contenido de id_ed25519.pub.

Con las claves funcionando, en un servidor expuesto a Internet se da el paso que cierra la puerta a los ataques por fuerza bruta: desactivar el ingreso con contraseña, poniendo PasswordAuthentication no en /etc/ssh/sshd_config. Es una edición de la configuración del servicio por el que se está conectado, y se hace con las precauciones del final del tema 39: probar con sudo sshd -t, recargar, y comprobar desde una segunda terminal antes de cerrar la primera.

12. ~/.ssh/config: nombres cortos

Usuario, dirección, puerto, archivo de clave: demasiado para escribir cada vez. ssh lee un archivo de configuración personal en el que cada máquina recibe un nombre corto, con todos sus datos.

Host servidor
    HostName 192.168.1.50
    User ana

Host web
    HostName 203.0.113.10
    User administrador
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

Host *
    ServerAliveInterval 60

ana@equipo:~$ chmod 600 ~/.ssh/config
ana@equipo:~$ ssh servidor                       # equivale a ssh ana@192.168.1.50
ana@servidor:~$ exit
ana@equipo:~$ ssh web 'uptime'                    # equivale a ssh -p 2222 administrador@203.0.113.10 'uptime'

Los nombres definidos allí valen para todos los programas que se apoyan en ssh, que son los de la sección siguiente, y se completan con Tab.

13. scp y rsync: copiar entre máquinas

scp, de secure copy, es cp a través de ssh. Tiene la misma forma —origen y destino— y la misma identificación; lo que agrega es una manera de nombrar un archivo que está en otra máquina:

ana@192.168.1.50:/var/log/syslog
       │        │      │
       │        │      └─ la ruta, en la máquina remota
       │        └─ los dos puntos: lo que hace que sea una ruta remota
       └─ usuario y máquina, como en ssh

ana@equipo:~$ cd ~/practica
ana@equipo:~/practica$ scp estado.txt servidor:/tmp/               # de aquí hacia allá
estado.txt                                    100%  437    98.2KB/s   00:00
ana@equipo:~/practica$ scp servidor:/etc/hostname .                # de allá hacia aquí
hostname                                      100%    9     3.1KB/s   00:00
ana@equipo:~/practica$ scp -r fotos servidor:respaldo/             # un directorio, con -r
ana@equipo:~/practica$ scp estado.txt servidor:                    # al directorio personal remoto

Las reglas son las de cp, del tema 11: -r para directorios, -p para conservar fechas y permisos, y el destino que puede ser un directorio o un nombre nuevo. Una ruta remota relativa parte del directorio personal del usuario en la otra máquina, y por eso servidor:, sin nada después, es ese directorio. El puerto se indica con -P, en mayúscula, a diferencia de ssh.

Para copiar un archivo, scp es suficiente. Para un directorio grande, o para repetir una copia, la herramienta es rsync, la que dejamos anotada en el tema 11. Compara origen y destino y transfiere solo lo que cambió; si se interrumpe, al repetir el comando continúa.

ana@equipo:~/practica$ rsync -av fotos/ servidor:respaldo/fotos/
sending incremental file list
./
playa.jpg
sierra.jpg
…
sent 856,402 bytes  received 133 bytes  342,614.00 bytes/sec
total size is 855,810  speedup is 1.00
ana@equipo:~/practica$ rsync -av fotos/ servidor:respaldo/fotos/   # otra vez: no hay nada que enviar
sending incremental file list

sent 198 bytes  received 12 bytes  140.00 bytes/sec
total size is 855,810  speedup is 4,075.29

Dos cuidados. La barra final del origen cambia el resultado: fotos/ significa «el contenido de fotos», y fotos, sin barra, «el directorio fotos», que se crearía dentro del destino. Y --delete borra: con el origen y el destino invertidos por error, vacía lo que se quería conservar. Antes de usarla se agrega -n, se lee lo que el comando anuncia, y recién entonces se lo ejecuta de verdad. rsync debe estar instalado en las dos máquinas, y sirve igual entre dos directorios de un mismo equipo.

14. Recetas y errores comunes

La referencia del tema:

Con este tema termina el bloque, y con él, el recorrido por las herramientas. Sabemos movernos por los archivos, procesar texto, gobernar procesos, administrar el sistema y trabajar en una máquina que no tenemos delante. En ~/practica quedó un archivo nuevo, gpl-3.0.txt. Varias veces, en estos temas, una línea de comandos resultó tan larga y tan útil que daba pena escribirla una sola vez: el informe de estado del tema 37, la búsqueda de lo que llena el disco, el diagnóstico de la red. El último bloque parte de ahí. En el tema 41 guardamos una secuencia de comandos en un archivo, le damos permiso de ejecución y la usamos como si fuera un comando más: el primer script.

15. Resumen

• Una comunicación de red involucra una interfaz, una dirección IP, una puerta de enlace, el DNS y un puerto. Cuando la red falla, uno de esos eslabones está roto.
• ip -br address muestra las interfaces, su estado y sus direcciones. 127.0.0.1 es la propia máquina; 192.168.x.x y 10.x.x.x son direcciones privadas.
• ip route muestra las rutas. La línea default indica la puerta de enlace; sin ella no se sale de la red local.
• Los nombres se traducen con /etc/hosts y con el DNS. host consulta el DNS, y resolvectl status dice qué servidor se usa.
• ping -c N comprueba si un destino responde. No se detiene solo sin -c. Que no responda no prueba que el equipo esté caído.
• La red se diagnostica en orden: interfaz, ruta, puerta de enlace, una dirección externa y, por último, un nombre.
• Un servicio escucha en un puerto. ss -tuln lista los puertos en escucha, y con sudo y -p, el programa de cada uno.
• Un servicio que escucha en 127.0.0.1 solo se alcanza desde la propia máquina; en 0.0.0.0, desde la red.
• Connection refused significa que nadie escucha en ese puerto; Connection timed out, que no hubo respuesta.
• curl escribe lo descargado en la salida estándar, y encaja en una tubería. Para guardar, -O; siempre con -f y -L. Con -I muestra el código de estado.
• wget descarga a un archivo, reintenta y retoma con -c.
• ssh usuario@máquina abre una terminal en otra máquina, cifrada. Lo que se ejecuta ocurre allá, y el indicador es lo que dice dónde se está.
• ssh máquina 'comando' ejecuta un comando remoto, cuya salida puede entrar en una tubería local.
• Un par de claves reemplaza a la contraseña: ssh-keygen lo genera y ssh-copy-id instala la pública en el servidor. La clave privada no se comparte nunca.
• ~/.ssh/config da nombres cortos a las conexiones.
• scp copia entre máquinas, con rutas remotas de la forma máquina:ruta. rsync -av transfiere solo lo que cambió.

16. Preguntas de repaso

Intenta responder cada una antes de abrir la respuesta.

Para practicar

1. Ejecuta ip -br address y luego ip address. ¿Cuántas interfaces tienes, cuál está en uso y cuál es su dirección? ¿Es privada? Averigua también tu dirección pública.
2. Identifica tu puerta de enlace con ip route. Consulta con ip route get el camino hacia 1.1.1.1, hacia la puerta de enlace y hacia 127.0.0.1.
3. Averigua qué servidor DNS usa tu equipo. Traduce tres nombres con host, y uno inventado. Compara host localhost con getent hosts localhost, y explica la diferencia.
4. Haz ping -c 5 a 127.0.0.1, a tu puerta de enlace y a un sitio de otro continente. Compara los tiempos y el ttl de los tres.
5. Recorre los cinco pasos de la sección 6 con la red funcionando, y anota el resultado de cada uno. Desconecta la red y repítelos: ¿cuál es el primero que falla, y con qué mensaje?
6. Lista los puertos en escucha con sudo ss -tulnp. Para cada uno, anota el programa y si es alcanzable desde la red. Busca tres de esos puertos en /etc/services.
7. Con curl, cuenta las líneas y las palabras de https://www.gnu.org/licenses/gpl-3.0.txt sin guardarlo, y muestra las diez palabras más frecuentes con los filtros del tema 26. Luego obtén solo el código de estado de esa dirección y de una que no exista.
8. Descarga el mismo archivo con wget y con curl -fLO. Repite los dos comandos: ¿qué hace cada uno con el archivo que ya existe? Calcula su suma con sha256sum en las dos copias.
9. Instala el servidor de ssh, o usa una segunda máquina. Conéctate, observa la pregunta de la huella y el cambio del indicador, y sal. Ejecuta de forma remota hostname, uptime y df -h /, sin abrir sesión.
10. Genera un par de claves, instálalo con ssh-copy-id y comprueba que ya no se pide la contraseña. Define un nombre corto en ~/.ssh/config, envía un archivo con scp y un directorio con rsync -av, y repite el rsync para ver que no transfiere nada.