SSH y Trabajo Remoto
Claves SSH, tmux, túneles y saltos de bastión: cómo los desarrolladores de Python acceden a las API de staging, siguen los logs de journald y reenvían puertos de bases de datos sin dejar claves sensibles en máquinas compartidas.
Busca en todas las páginas de la documentación
Claves SSH, tmux, túneles y saltos de bastión: cómo los desarrolladores de Python acceden a las API de staging, siguen los logs de journald y reenvían puertos de bases de datos sin dejar claves sensibles en máquinas compartidas.
ssh -A -J bastion@jump.acme.com deploy@staging-api.internal
tmux new -s triage
sudo journalctl -u billing-api -fCuándo usar esto:
uv run de larga duración con tmux a prueba de desconexiones# ~/.ssh/config
Host bastion
HostName jump.acme.com
User ubuntu
IdentityFile ~/.ssh/id_ed25519
Host staging-api
HostName 10.0.2.15
User deploy
ProxyJump bastion
LocalForward 15432 staging-db.internal:5432
# Conectar y reenviar DB para psql local
ssh staging-api
# otra terminal:
psql "postgresql://user@localhost:15432/billing"
# La sesión de tmux sobrevive a la suspensión del portátil
tmux new -s migrate
uv run alembic upgrade head
# desvincular: Ctrl-b dLo que esto demuestra:
ProxyJump a través de un bastión sin doble SSH manualLocalForward mapea la DB remota a localhost-A reenvía el agente para git pull en remoto; usar con precaución.LocalForward (remoto a local), RemoteForward (local a remoto), DynamicForward SOCKS.| Paso | Comando |
|---|---|
| Probar conexión | ssh -G staging-api configuración en seco |
| Iniciar sesión | tmux new -s work |
| Seguir logs | journalctl -f |
| Copiar artefacto | scp -J bastion file deploy@host:/tmp/ |
# Comprobación de estado remota en una línea
ssh staging-api 'curl -sf http://localhost:8000/health'
# Sincronizar archivo de entorno de forma segura (evitar si hay secretos en el archivo - usar vault)
scp -J bastion .env.example deploy@staging-api:/opt/billing-api/-A en producción a menos que sea necesario.LocalForward expuesto en 0.0.0.0 - DB accesible en la WiFi del café. Solución: enlazar 127.0.0.1:15432:....SSH StrictHostKeyChecking desactivado globalmente - Riesgo de MITM. Solución: known_hosts por entorno.rsync -e ssh para sincronización de artefactos grandes.| Alternativa | Usar Cuando | No Usar Cuando |
|---|---|---|
| AWS SSM Session Manager | Sin claves SSH en VMs | Solo SSH en entornos locales |
| Teleport / Boundary | Acceso privilegiado auditado | Un pequeño equipo con bastión está bien |
| GitHub Codespaces | Entorno de desarrollo en la nube | Acceso a datos de producción prohibido |
| VPN | Acceso a subred completa | Solo se necesita un reenvío de DB |
Ed25519 por defecto para claves nuevas - más corta, segura; RSA solo para sistemas heredados.
La integración con el llavero --apple-use-keychain almacena la frase de contraseña de forma segura.
tmux es el predeterminado moderno; mismo objetivo de persistencia.
mosh roaming UDP - bueno para viajar; requiere paquete de servidor.
ssh -R 8080:localhost:8000 expone FastAPI local temporalmente - riesgo de seguridad, limita el tiempo de uso.
Utiliza la misma configuración SSH; asegúrate de que el entorno remoto tenga uv y el proyecto clonado.
sftp interactivo; scp de un solo uso - rsync es mejor para directorios de despliegue.
Host github.com-work con IdentityFile en la configuración SSH por organización.
Algunos requisitos de cumplimiento exigen script o grabación de sesiones de teleport en producción.
AddressFamily inet explícito si el enrutamiento v6 está roto en la red corporativa.
Versiones de Stack: Esta página fue escrita para Python 3.14.0 (estable 3.14, mantenimiento 3.13), FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+, y uv 0.6+.
Revisado por Chris St. John·Última actualización: 16 jul 2026