---
title: "SSH sin teclear usuario ni IP: ssh-copy-id y ~/.ssh/config"
description: "Entrar por SSH sin teclear usuario ni IP: una clave Ed25519 con passphrase, ssh-copy-id para dejarla en el servidor y un alias en ~/.ssh/config."
date: 2026-11-07
locale: es
tags: [homelab]
summary: "Cómo dejé de teclear usuario, IP y contraseña en cada conexión SSH: una clave Ed25519 con passphrase, ssh-copy-id para dejarla en el servidor, y un bloque Host en ~/.ssh/config para entrar con un alias. Incluye cuándo desactivar PasswordAuthentication: solo después de comprobar que la clave funciona."
url: https://escribano.dev/es/blog/023-ssh-keys-config/
---
Recuerdo las primeras veces que usé SSH para administrar un servidor casero. Fue con un ordenador comprado en 1997: originalmente tenía 16 MB de RAM y le monté módulos de segunda mano de eBay hasta llegar a 128 MB. Le instalé Debian Woody siguiendo una guía que me habían pasado, impresa en papel.

Creo que fue hacia 2004. La instalación la hice en la habitación del sobremesa, con un CD netinst y el monitor y teclado de ese equipo; en pocos minutos tenía un Debian mínimo. Después llevé la torre a una habitación que no usaba nadie, la dejé junto al router y la conecté con dos cables: uno de red y otro de alimentación. Sin ratón, sin teclado, sin pantalla. Ver aquel equipo encendido, sin nada con lo que interactuar, me provocó una sensación extraña. Solo tenía una forma de entrar: SSH.

Recuerdo el ritual de escribir en la terminal del equipo principal algo como `ssh ruben@192.168.1.81`. El servidor casero respondía al momento pidiendo la contraseña, y ya estaba dentro. Luego venía seguir la guía paso a paso. La mayoría de los pasos eran instalar aplicaciones, y creo que la primera era Midnight Commander, para usar su editor `mcedit`, un editor sencillo y práctico del estilo de `nano`.

Escribí `apt-get install mc` y vi cómo, en pocos segundos, empezaba a descargar e instalar solo. Al poco tenía el comando `mcedit` disponible. Aquello me descolocó un poco, y la razón viene de lejos. Los equipos de solo texto de los 80 no se conectaban a Internet. El primero que vi conectado fue, creo, uno con Windows 3.11 en el aula de informática del instituto, en 1995: el único de unos quince que tenía conexión. Para mí, lo de texto era de otra época e Internet iba ligado a lo gráfico, y un Debian pelado descargando programas desde la terminal daba la vuelta a esa asociación.

Volviendo a 2004: desde la sesión SSH veía cómo aquel Debian descargaba, una a una, las aplicaciones de la guía, y editaba los ficheros de configuración con `mcedit`. Al terminar tenía un servidor casero con cortafuegos, FTP, LAMP y alguna cosa más, y la barrera mental ya estaba superada.

Aunque quedaba una parte donde había fricción: el momento de tener que recordar el usuario, la IP (o dominio) y la contraseña. Al principio tiene su magia escribirlo a mano, pero cuando necesitas hacerlo a diario, o cuando solo te conectas de forma muy puntual a un VPS, se te puede olvidar.

Aquí entran dos conceptos que todo el que usa SSH debería conocer: `ssh-copy-id` y el fichero `~/.ssh/config`.

## Primero, la clave

En el equipo principal genero un par de claves Ed25519:

```bash
ssh-keygen -t ed25519 -C "ruben@escribano.dev"
```

El comando pide una passphrase para proteger la clave privada. La diferencia con la contraseña de SSH es dónde se usa: la contraseña viajaba al servidor (cifrada) en cada conexión y la comprobaba él; la passphrase nunca sale de tu equipo, solo desbloquea la clave privada en local. Si quieres profundizar en la diferencia entre contraseña y clave, la traté en [la entropía de las contraseñas](/blog/010-password-entropy-length/); la passphrase la genero con el mismo criterio que el resto de mis secretos ([mi sistema de bóveda](/blog/011-tales-vault-system/)).

Para no escribirla en cada conexión, la clave se carga en `ssh-agent` con `ssh-add`; otra vía es `AddKeysToAgent yes` en el bloque `Host` de `~/.ssh/config`, que la deja en el agente la primera vez que la usas. Ambas requieren un agente en marcha; los de escritorio (GNOME, macOS) lo tienen y se ocupan de esto solos.

## Copiar la clave: ssh-copy-id

Teclear la contraseña queda para una sola vez por máquina:

```bash
ssh-copy-id ruben@192.168.7.149
```

Lo que hace es simple: añade tu clave pública al final de `~/.ssh/authorized_keys` del servidor; si el directorio `~/.ssh` o el fichero no existen, los crea con permisos `700` y `600` respectivamente.

A partir de ahí, `ssh ruben@192.168.7.149` entra sin pedir contraseña: solo queda la passphrase, una vez por sesión.

Abre una terminal nueva y comprueba que entras sin contraseña. Hasta que eso funcione, no toques la configuración del servidor: el paso del final del post espera a que lo haga.

## El alias: ~/.ssh/config

La clave ya está; quedan el usuario y la IP. Todo cabe en el fichero `~/.ssh/config` de mi equipo principal:

```ssh-config
Host sam
    HostName 192.168.7.149
    User ruben
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes
    AddKeysToAgent yes
```

`sam` es una máquina virtual de VirtualBox a la que fijé una IP estática dentro de mi red local, para que la conexión no dependa del DHCP. A partir de ahora, la conexión es `ssh sam`. El `IdentityFile` es opcional si solo tienes una clave (SSH prueba las habituales), pero lo dejo explícito para cuando empiezan a acumularse claves por rol. Lo acompaño de `IdentitiesOnly yes`: sin él, SSH ofrece todas las claves del agente, y con demasiadas el servidor corta la conexión antes de llegar a la buena.

El fichero admite más de lo que parece: patrones (`Host vps-*` con opciones compartidas), varios nombres en un mismo `Host`, opciones por bloque. Yo casi no uso nada de eso; un bloque corto por máquina me basta.

Si algo falla, dos comandos de diagnóstico:

```bash
ssh -G sam   # la configuración exacta que SSH va a aplicar
ssh -v sam   # qué claves ofrece el cliente en cada intento
```

Con `ssh -v` ves qué claves ofrece el cliente en cada intento, pero no por qué las rechaza el servidor: si el problema son los permisos de `authorized_keys`, solo aparece `Permission denied (publickey)`, y el motivo está en el log del servidor (`journalctl -u ssh`, o `/var/log/auth.log` si tu Debian usa rsyslog). Si la clave no está en el agente, no hay error que rastrear: SSH te pide la passphrase y sigue.

## Desactivar la contraseña (al final, no antes)

Cuando todas las conexiones a un servidor entran con la clave, el paso final es quitar la contraseña: en `/etc/ssh/sshd_config` del servidor,

```
PasswordAuthentication no
```

En Debian el servicio se llama `ssh`. Antes de aplicar el cambio, lo valido y lo recargo:

```bash
sudo sshd -t
sudo systemctl reload ssh
```

`sshd -t` comprueba la configuración antes de aplicarla y `reload` la recarga sin tocar las sesiones abiertas. Aun así, no cierres la sesión antigua hasta haber probado una nueva: si algo falla, sigues dentro y reviertes con calma.

En mi caso las máquinas están tras la red del homelab y no exponen SSH a Internet, así que me queda como higiene de base. En un VPS expuesto, el paso es prioritario: los bots que prueban contraseñas no descansan. Allí, además, conviene revisar los ficheros de `/etc/ssh/sshd_config.d/`: sshd usa el primer valor que lee, y un fichero tipo `50-cloud-init.conf` puede dejar `PasswordAuthentication yes` por delante del cambio en el fichero principal. Comprueba el valor efectivo con `sudo sshd -T | grep passwordauthentication`.

## Cierre

Aquel equipo de 1997 con Debian Woody hacía exactamente lo que hace `sam` hoy: esperar una conexión por SSH. Lo que queda de fricción es poco: copiar la clave una vez por máquina y teclear la passphrase una vez por sesión.

Si todavía hay una máquina a la que llegas de memoria (usuario, IP, contraseña), empieza por ella: una clave, un `ssh-copy-id` y un bloque corto en `~/.ssh/config`.