- ¿Por qué debería crear y utilizar una clave SSH?
- Prerrequisitos y conceptos básicos
- Creación de una clave SSH en Linux/macOS/WSL
- Creación de una clave SSH en Windows (PowerShell / Windows OpenSSH)
- Importación de claves públicas en AWS EC2 y otros paneles en la nube
- Agregar clave a GitLab/GitHub y usar en CI
- Configuración del servidor y de seguridad después de la instalación de la clave
- Consejos prácticos para diferentes aplicaciones
- Gestión de claves, rotación y estándares
- Consejos adicionales y solución de problemas
- Recomendaciones finales de seguridad
- Resumen y lista de verificación sugerida
¿Por qué debería crear y utilizar una clave SSH?
En entornos de nube y centros de datos internacionales, el inicio de sesión seguro y automatizado a los servidores es una piedra angular de cada operación de DevOps, alojamiento web, renderizado, IA y gestión de bases de datos. Claves SSH Son un método estándar, seguro y programable para la autenticación y reemplazan contraseñas débiles.
El uso de claves públicas y privadas reduce el riesgo de ataques de fuerza bruta y facilita la automatización y la implementación de controles de acceso más detallados.
Prerrequisitos y conceptos básicos
Clave privada: Su archivo confidencial que no debe ser divulgado.
Clave pública: Un archivo que se coloca en el servidor (authorized_keys).
Algoritmos comunes: ed25519 (Recomendado), RSA 4096.
Rutas: ~/.ssh/id_* En Linux/WSL y C:\Usuarios\ \.ssh En Windows.
Accesos: chmod 700 ~/.ssh y chmod 600 Para la clave privada.
Creación de una clave SSH en Linux/macOS/WSL
Se recomienda ed25519 Úselo a menos que necesite RSA por razones de compatibilidad.
Pasos para generar y administrar claves en Shell
ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/id_ed25519 -o -a 100
ssh-keygen -t rsa -b 4096 -C "[email protected]" -f ~/.ssh/id_rsa -o -a 100
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
ls -la ~/.ssh
cat ~/.ssh/id_ed25519.pub
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 [email protected]
chmod 400 my-aws-key.pem
ssh -i my-aws-key.pem [email protected]Nota: En AWS, la clave suele elegirse o importarse al iniciar una instancia. Si tiene un archivo PEM, úselo como identidad.
Creación de una clave SSH en Windows (PowerShell / Windows OpenSSH)
Windows 10/11 tiene un cliente OpenSSH; también puede usar PuTTY/Puttygen para conectarse con PuTTY.
Comandos de PowerShell
ssh-keygen -t ed25519 -C "[email protected]" -f $env:USERPROFILE\.ssh\id_ed25519
Start-Service ssh-agent
ssh-add $env:USERPROFILE\.ssh\id_ed25519Ruta del archivo:
C:\Usuarios\ \.ssh\id_ed25519C:\Usuarios\ \.ssh\id_ed25519.pub
Convierta PEM a PPK con PuTTYgen
Pasos generales:
Abra PuTTYgen.
Archivo > Cargar clave privada y archivo
mi-clave-aws.pemCargar (mostrar todos los archivos).Guardar clave privada como
mi-clave-aws.ppkY úselo en PuTTY (Conexión > SSH > Autenticación > Archivo de clave privada).
Importación de claves públicas en AWS EC2 y otros paneles en la nube
Consola de AWS: EC2 > Pares de claves > Importar par de claves. Nombre y contenido del archivo .pub Ingresar.
Al crear una instancia, puede seleccionar un par de claves existente. Otros centros de datos suelen tener la opción "Cargar/Importar clave SSH" en el panel.
Ejemplo de cloud-init para agregar una clave pública
#cloud-config
ssh_authorized_keys:
- ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... [email protected]Agregar clave a GitLab/GitHub y usar en CI
Para GitLab: Configuración de usuario > Claves SSH Pegue la clave pública. Vaya al proyecto para implementar claves.
En CI/CD, cargue la clave privada como una variable protegida y úsela en el trabajo creando un archivo con acceso restringido (chmod 600).
Configuración del servidor y de seguridad después de la instalación de la clave
Paso 1: Establecer permisos.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519Luego, la configuración /etc/ssh/sshd_config Comprobar y actualizar:
Número de autenticación de contraseña
No se permite el inicio de sesión raíz
Autenticación de clave pública sí
Puede Permitir usuarios Establecer para restringir usuarios.
No usar DNS Y cambia el puerto si lo deseas.
sudo systemctl restart sshdCortafuegos:
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw allow 2222/tcpUtilice Fail2ban o CrowdSec para evitar la fuerza bruta:
sudo apt install fail2banPara servidores sensibles, utilice bastión/host de salto para restringir el acceso directo a redes privadas.
Consejos prácticos para diferentes aplicaciones
Para comerciantes (VPS para comercio)
Elija una ubicación: Cerca de servidores de brókeres o exchanges para una latencia mínima. Contamos con más de 85 ubicaciones globales que pueden proporcionar una ubicación cercana a su mercado objetivo.
Se recomienda restringir SSH solo a IP estática o mediante VPN:
sudo ufw allow from 203.0.113.5 to any port 22Para jugadores (VPS para juegos)
Para servidores de juegos, utilice ubicaciones con un peering sólido y una CDN/BGP adecuada. Use claves SSH en lugar de contraseñas y un host bastión para reducir la superficie de ataque.
Para IA y renderizado (GPU Cloud)
Utilice claves seguras (ed25519/RSA4096) para conectarse a servidores GPU y asignar un usuario y una clave separados para cada proyecto.
rsync -avz -e "ssh -i ~/.ssh/id_ed25519 -p 2222" /local/path user@remote:/remote/pathPara alojamiento y alojamiento de GitLab
Utilice una clave específica del servidor (clave de implementación) con acceso limitado para acceder automáticamente al servidor a los repositorios privados.
Gestión de claves, rotación y estándares
Gire las llaves periódicamente (por ejemplo, cada 6 a 12 meses).
Retire las llaves viejas de
claves autorizadasY eliminar el panel de nubes.Utilice la frase de contraseña para la clave privada y guárdela en un administrador de contraseñas.
En las organizaciones, utilice certificados SSH y CA para la gestión centralizada (OpenSSH CA).
Consejos adicionales y solución de problemas
Cuando nos enfrentamos a un error Permiso denegado (clave pública) Compruebe que la clave pública esté en ~/.ssh/claves_autorizadas Existe y los permisos son correctos.
sudo journalctl -u sshd -e
sudo tail -f /var/log/auth.logSi está utilizando ProxyJump o Jump Host, el archivo de configuración es útil:
Host bastion
HostName bastion.example.com
User ubuntu
IdentityFile ~/.ssh/id_ed25519
Host internal-*
ProxyJump bastion
User deploy
IdentityFile ~/.ssh/id_deployDe Intervalo de vida del servidor y Conteo máximo de servidores vivos Úselo en la configuración ssh para evitar la finalización repentina de sesiones.
Recomendaciones finales de seguridad
Restringir el acceso SSH a las IP, utilizar una VPN o red privada y utilizar servicios anti-DDoS para servidores sensibles son otros puntos importantes.
Resumen y lista de verificación sugerida
Creación de claves: ed25519 con frase de contraseña
Protección de archivos:
chmod 700 ~/.ssh && chmod 600 clave privadaActivación del agente SSH y adición de claves
Cargue la clave pública en el panel o centro de datos de AWS o utilice cloud-init
Desactivación de la autenticación con contraseña y PermitRootLogin
Cortafuegos/UFW y Fail2ban o CrowdSec
Uso de bastión, restricción de IP y VPN para acceso sensible
Duplicación y rotación periódica de llaves









