Cómo usar SCP en Linux: la guía completa 2026

SCP es la herramienta de copia remota por SSH más usada en Linux. Esta guía cubre desde el comando básico hasta el troubleshooting de los problemas más comunes (permission denied, host key verification failed, scp deprecated en RHEL 9) y cuándo conviene saltar a rsync o sftp.

---

Qué es SCP y por qué sigue siendo relevante

SCP (Secure Copy Protocol) copia archivos entre dos hosts usando SSH como transporte. A diferencia de cp que solo trabaja en el sistema de archivos local, scp cifra todo el tráfico en el canal SSH, por lo que es seguro correrlo sobre redes públicas. El protocolo SCP (parte de SSH 1.2.0) data de 1996. Tatu Ylönen creó SSH en 1995; OpenSSH es un fork de 1999 del equipo OpenBSD (liderado por Theo de Raadt), no del mismo autor. El binario scp sigue siendo parte del paquete openssh-client en cualquier distribución Linux moderna.

A pesar de los cambios de los últimos años — OpenSSH 9.0 (abril 2022) deprecó el protocolo SCP y desde RHEL 9 el binario scp usa SFTP por debajo — el comando sigue funcionando exactamente igual desde la línea de comandos del usuario. Lo que cambió fue la implementación interna: el cliente ya no habla el protocolo SCP viejo (que tenía un bug serio, CVE-2020-15778, vulnerable a inyección de comandos), sino que negocia SFTP sobre la conexión SSH. Para el sysadmin que corre scp archivo usuario@servidor:/destino, esto es transparente: la sintaxis es la misma, las opciones son las mismas, y la seguridad es mejor.

¿Cuándo usar SCP? Para transferencias puntuales de pocos archivos, scripts rápidos, mover configs entre servidores, o hacer deploy de un binario. Para sincronizaciones grandes, recurrentes o que necesitan resume, conviene rsync — lo cubrimos al final de la guía.

---

Requisitos

• Linux, macOS o Windows con OpenSSH (Windows 10+ tiene scp nativo en PowerShell y cmd)
• Acceso SSH al servidor remoto: usuario, hostname/IP y puerto
• Autenticación por clave ed25519 (recomendado) o password
• Permiso de escritura en el directorio destino del servidor remoto
• OpenSSH >= 6.5 en cliente y servidor (cualquier distro post-2014)

verifica tu versión antes de empezar:

scp -V
# scp: OpenSSH_9.6p1, OpenSSL 3.0.13

---

Paso 1: Sintaxis básica de SCP

SCP usa la misma sintaxis que cp: primero el origen, después el destino, con la opción -r para recursivo. La diferencia es que origen o destino pueden ser remotos (formato usuario@host:ruta).

# Copiar archivo local a remoto
scp archivo.txt usuario@servidor:/home/usuario/
# Copiar archivo remoto a local
scp usuario@servidor:/home/usuario/archivo.txt ./
# Copiar entre dos hosts remotos (a través de tu máquina)
scp usuario@servidor1:/etc/app.conf usuario@servidor2:/etc/app.conf

¿Por qué importa el orden de los argumentos? SCP no tiene --source y --destination explícitos. El primero siempre es origen, el segundo destino. Si te equivocas, en lugar de subir el archivo lo bajás al directorio actual (con el nombre del path remoto, así que terminás con un archivo llamado home o un directorio raro). Siempre verifica dos veces antes de ejecutar en producción.

Si ves errores tipo scp: ambiguous target o scp: No such file or directory, casi siempre es que el path remoto está mal escrito o falta el : después del host.

---

Paso 2: Especificar puerto, clave y opciones comunes

La mayoría de los servidores SSH no escuchan en el puerto 22 (es el primer puerto que cualquier botnet escanea). Lo estándar es usar un puerto alto (2222, 65002, 22222). SCP usa -P mayúscula para especificar el puerto. Hay otras opciones en mayúscula también: -O (legacy protocol), -S (programa a usar en vez de ssh), y -D (SOCKS). El resto sí son minúsculas. Si usas -p minúscula, no cambiás el puerto sino que pedís que se preserven los timestamps del archivo.

# Puerto custom
scp -P 2222 archivo.txt usuario@servidor:/destino/
# Usar una clave SSH específica (no la default id_ed25519)
scp -i ~/.ssh/id_mi_servidor archivo.txt usuario@servidor:/destino/
# Preservar timestamps, permisos y ownership (-p minúscula)
scp -p archivo.txt usuario@servidor:/destino/
# Modo verboso: muestra qué archivos se transfieren y dónde
scp -v archivo.txt usuario@servidor:/destino/
# Compresión: útil en conexiones lentas (WiFi, mobile, satelital)
scp -C archivo.txt usuario@servidor:/destino/
# Limitar ancho de banda a 500 Kbit/s (importante en producción)
scp -l 500 archivo-grande.iso usuario@servidor:/destino/
# Combinar varias opciones
scp -P 2222 -i ~/.ssh/id_produccion -C archivo.zip usuario@servidor:/var/www/

¿Por qué importa la opción -l? Sin límite de ancho de banda, SCP consume todo el uplink disponible. Si lo corres desde un servidor de producción mientras los usuarios están trabajando, vas a tirarles la red. -l 5000 (5 Mbps) es un valor razonable para backups en horario laboral. Para transferencias masivas fuera de horario, dejá sin límite.

Si ves Permission denied (publickey,password): el servidor rechaza tu clave. verifica que ~/.ssh/authorized_keys en el servidor contiene tu clave pública (cat ~/.ssh/id_ed25519.pub), que los permisos del directorio ~/.ssh son 700 y del archivo 600, y que el servidor está aceptando esa clave en /etc/ssh/sshd_config (PubkeyAuthentication yes).

---

Paso 3: Copiar directorios recursivos

Para copiar un directorio entero usas -r (recursivo). Sin esta flag, SCP se queja cuando el origen es un directorio y no copia nada.

# Copiar directorio local a remoto
scp -r ./mi-proyecto/ usuario@servidor:/var/www/
# Copiar directorio remoto a local
scp -r usuario@servidor:/var/log/mi-app/ ./logs/
# Copiar solo ciertos archivos (usando wildcard)
scp -r usuario@servidor:/var/log/*.log ./logs/
# Para excluir archivos específicos SCP NO tiene --exclude (es de rsync).
# Workaround: usar rsync sobre SSH:
rsync -av --exclude="*.tmp" --exclude=".git/" ./proyecto/ usuario@servidor:/srv/

¿Por qué importa el wildcard? En SCP, los wildcards (.log, ?, [abc]) se interpretan en el shell local, no en el servidor remoto. Si quieres que se expandan en el remoto, tienes que escaparlos: scp 'usuario@servidor:/var/log/.log' ./logs/. Sin las comillas, tu shell local busca los .log en tu directorio actual y falla con “no such file”.

Cuidado con node_modules, .git, vendor/: SCP no sabe qué ignorar. Si copiás un proyecto de 500 MB y dentro hay un node_modules de 800 MB, te llevás todo. usa --exclude o copiá primero a un tarball (tar czf - proyecto/ | ssh usuario@servidor 'tar xzf - -C /destino/'), que es más eficiente porque comprime antes de transferir.

---

Paso 4: Forzar IPv4, IPv6 o SSH específico

En redes modernas con dual-stack (IPv4 + IPv6), SCP puede confundirse y tardar segundos extra intentando IPv6 cuando el server solo tiene IPv4 configurada correctamente. -4 y -6 fuerzan una u otra.

# Forzar IPv4
scp -4 archivo.txt usuario@servidor:/destino/
# Forzar IPv6
scp -6 archivo.txt usuario@[2001:db8::1]:/destino/
# Especificar binario de SSH alternativo (ej: usar ssh de Termux en lugar del del sistema)
scp -S /usr/local/bin/ssh archivo.txt usuario@servidor:/destino/

¿Por qué importa IPv6 vs IPv4? Muchas ISPs y datacenters ya dan IPv6 nativo. Si tu ~/.ssh/config tiene un Host servidor con AddressFamily any, SCP prueba primero IPv6, después IPv4. En servers que solo escuchan en una de las dos, perdés 1-2 segundos en el timeout. -4 o -6 lo arregla. También puedes configurar ~/.ssh/config para que recuerde la preferencia por host:

Host mi-servidor
    AddressFamily inet
    Port 2222
    User deploy
    IdentityFile ~/.ssh/id_produccion

Con esa config, scp archivo mi-servidor:/destino/ ya sabe todo sin que tengas que pasarle las flags.

Si ves ssh: connect to host X port 22: Connection timed out: prueba -4 o -6. También verifica que el firewall del server acepta tu IP (sudo ufw status o sudo iptables -L -n). En AWS, GCP y Azure, las VMs nuevas tienen firewall por defecto que bloquea todo lo que no esté en el security group.

---

Paso 5: Ver el progreso de la transferencia

Por defecto SCP no muestra progreso hasta que termina. Para archivos grandes (varios GB) quieres ver cuánto lleva y cuánto falta. -v (verbose) lo muestra pero es muy ruidoso. La mejor opción es redirigir la salida para que no contamine tu terminal:

# Ver progreso en bytes (sin verbose ruidoso)
scp -p archivo-grande.iso usuario@servidor:/destino/ 2>&1 | grep -E '%|KB|MB|GB'
# O usar pv (pipe viewer) si está instalado
pv archivo-grande.iso | ssh usuario@servidor 'cat > /destino/archivo-grande.iso'
# Limitar el rate y ver el progreso combinado
scp -l 8000 archivo-grande.iso usuario@servidor:/destino/

¿Por qué importa ver el progreso? En una transferencia de 10 GB sobre una conexión de 50 Mbps (~6 MB/s efectivos), el tiempo teórico es ~28 minutos; si scp va a 200 KB/s sospechá cuello de botella porque algo está mal (cuello de botella en el server, throttling del ISP). Sin progreso, pensás que se colgó y cancelás a los 30 segundos, justo cuando ya iba a terminar.

Limitación real de SCP: no tiene resume nativo. Si la conexión se corta a 7 GB de 10 GB, perdiste esos 7 GB y tienes que empezar de cero. Para transferencias grandes y poco confiables (WiFi público, conexión celular), rsync con -P es la respuesta — lo vemos en la sección de comparación.

---

Paso 6: Automatizar SCP con claves ed25519

Cada vez que corres SCP te pide password (si no tienes clave SSH configurada). En scripts de deploy, backups programados, o tareas de cron, esto no es viable. La solución es autenticación por clave pública.

# 1. Generar clave ed25519 (si no tienes una)
ssh-keygen -t ed25519 -a 100 -C "[email protected]"
# 2. Copiar la clave pública al servidor (ssh-copy-id es la forma más fácil)
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 usuario@servidor
# 3. Probar que funciona sin password
ssh -p 2222 usuario@servidor 'echo "autenticación OK"'
# 4. Ahora SCP también la usa automáticamente
scp -P 2222 archivo.txt usuario@servidor:/destino/

¿Por qué importa usar ed25519 y no RSA? ed25519 (curvas elípticas) genera claves más cortas (68 caracteres vs 544 de RSA-3072), la verificación es ~10x más rápida, y resiste ataques de timing side-channel por diseño. RSA-2048 todavía funciona pero NIST recomienda migrar desde 2024. Para más detalle sobre generación, instalación de clave pública y hardening completo, mira la guía de claves SSH ed25519.

Cuidado con passphrase + cron: si tu clave tiene passphrase (recomendado), un cronjob no puede usarla directamente porque no hay TTY para pedir el password. Las opciones son:

# Opción 1: ssh-agent en el cronjob (mantiene la clave desbloqueada un rato)
eval $(ssh-agent) && ssh-add ~/.ssh/id_ed25519
scp archivo usuario@servidor:/destino/
# Opción 2: clave separada SIN passphrase para automatización (menos seguro)
ssh-keygen -t ed25519 -f ~/.ssh/id_autodeploy -N "" -C "autodeploy@server"
# Opción 3: usar sshpass (mala idea, expone el password en la línea de comandos)

Si ves sign_and_send_pubkey: signing failed: agent refused operation: el ssh-agent está corriendo pero la clave no se cargó. ssh-add -l te lista las claves cargadas. Si está vacía, ssh-add ~/.ssh/id_ed25519 y metés la passphrase una vez.

---

SCP vs rsync vs sftp: cuándo usar cada uno

Los tres protocolos hacen lo mismo (transferir archivos sobre SSH) pero tienen diferencias importantes. Acá la guía de decisión rápida:

Característica	SCP	rsync	SFTP
Resume de transferencias interrumpidas	No	Sí (-P o --partial)	Sí (reget)
Compresión	Sí (-C)	Sí (-z)	No nativa (tunelar SSH)
Sync incremental (solo lo que cambió)	No	Sí (default)	No
Listar/navegar directorio remoto	No	No (rsync solo transfiere)	Sí (ls, cd, pwd) interactivo
Copia recursiva de directorios	Sí (-r)	Sí (default)	Sí (get -r)
Overhead de protocolo	Bajo	Medio	Medio-alto
Velocidad en transferencias únicas pequeñas	La más rápida	Igual o un poco más lenta	Más lenta
Disponible por defecto en OpenSSH	Sí	No (instalar paquete)	Sí

Regla práctica que uso hace años:

• SCP para uno o dos archivos, scripts rápidos, deploy de un binario, copiar una config. Cuando la transferencia es única y corta, SCP es el más simple y rápido.
• rsync para sincronizaciones grandes (GBs), backups, deploys de directorios, cuando la red puede caerse y quieres resume. rsync -avzP --progress ./proyecto/ usuario@servidor:/destino/ es el patrón canónico.
• SFTP cuando necesitas navegar el filesystem remoto de forma interactiva (similar a FTP), reanudar descargas parciales, o hacer operaciones tipo rename/chmod remotas.

Ejemplo de rsync equivalente al SCP recursivo, con resume y progreso:

# SCP equivalente (sin resume, sin progreso detallado)
scp -r ./proyecto/ usuario@servidor:/var/www/
# rsync equivalente (con resume, progreso, compresión)
rsync -avzP --progress ./proyecto/ usuario@servidor:/var/www/

Nota sobre la deprecación del protocolo SCP: desde OpenSSH 9.0 (abril 2022), el binario scp ya no habla el protocolo SCP original — usa SFTP por debajo cuando los dos lados son OpenSSH modernos. Esto es transparente para ti, pero significa que técnicamente ya no hay un protocolo “SCP puro” en uso en sistemas actualizados. Para más detalle, mira el thread original de OpenSSH sobre la deprecación.

---

Troubleshooting: los 5 errores más comunes de SCP

1. Permission denied (publickey,password)

La autenticación falla. Causas más frecuentes en orden:

# verifica que la clave está en el servidor
ssh usuario@servidor 'cat ~/.ssh/authorized_keys'
# Permisos correctos son críticos
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
# verifica que el servidor acepta autenticación por clave
ssh usuario@servidor 'sudo grep -i pubkey /etc/ssh/sshd_config'
# PubkeyAuthentication yes   ← debe estar yes
# Probar con verbose para ver exactamente dónde falla
scp -vvv archivo.txt usuario@servidor:/destino/

2. Host key verification failed

El servidor cambió su clave de host (o es la primera vez que te conectás). SCP reusa la config de known_hosts que tiene ssh. Si el server fue re-instalado, la clave nueva no matchea.

# Opción 1: borrar la entrada vieja (solo si estás seguro de que es el server correcto)
ssh-keygen -R servidor
# Opción 2: deshabilitar la verificación temporalmente (peligroso en producción)
scp -o StrictHostKeyChecking=no archivo.txt usuario@servidor:/destino/
# Opción 3: aceptar la nueva clave interactivamente la primera vez
ssh usuario@servidor 'echo OK'  # responde "yes" cuando pregunta

3. scp: No such file or directory o scp: ambiguous target

El path destino no existe o tienes un espacio sin escapar. Causas comunes:

# Path con espacios: usar comillas o escapar
scp archivo.txt "usuario@servidor:/mis documentos/"
# Path absoluto mal escrito: verificar que existe primero
ssh usuario@servidor 'ls -la /destino/'
# Path relativo en remoto: SCP no soporta ~ en destino remoto en algunas versiones
scp archivo.txt usuario@servidor:./   # directorio home, OK
scp archivo.txt usuario@servidor:~/   # algunas versiones, falla

4. Conexión se corta a mitad de transferencia (sin resume)

SCP no puede resumir. Si la transferencia se corta (WiFi inestable, timeout del firewall, NAT agresivo), empezás de cero. Soluciones:

# Migrar a rsync con -P (resume + progress)
rsync -avzP --partial archivo-grande.iso usuario@servidor:/destino/
# O usar scp en loop manual (no ideal pero funciona)
while ! scp archivo-grande.iso usuario@servidor:/destino/; do
  echo "Reintentando en 5 segundos..."
  sleep 5
done

5. scp: command not found en el servidor remoto

El server remoto no tiene openssh-client (caso raro pero pasa en containers minimalistas, Alpine, busybox). Como SCP usa SSH para ejecutar el binario scp en el otro lado, si el server no lo tiene, falla.

# En Debian/Ubuntu server
sudo apt install openssh-client
# En RHEL/CentOS/AlmaLinux
sudo dnf install openssh-clients
# En Alpine
sudo apk add openssh-client
# Workaround: usar SFTP que suele estar en el mismo paquete
sftp usuario@servidor

---

Conclusión

SCP es la herramienta correcta para transferencias puntuales y rápidas de archivos entre hosts Linux. La sintaxis es simple (origen + destino, con -r para directorios), las opciones que realmente importan son pocas (-P para puerto, -i para clave, -C para comprimir, -l para limitar ancho de banda), y la autenticación por clave ed25519 elimina el password.

Para workflows más serios (deploys automatizados, backups recurrentes, transferencias de GBs que se pueden interrumpir) migrá a rsync con -avzP — tienes resume, progreso, sync incremental y la misma sintaxis básica. Para navegación interactiva del server, usa sftp en una sesión shell.

Si estás configurando SCP por primera vez y todavía no tienes clave ed25519, empezá por ahí — la guía completa de claves SSH ed25519 cubre generación, instalación en el servidor, y hardening del sshd_config.

Resumen de los flags más usados:

• -P puerto — puerto SSH custom (mayúscula)
• -p — preservar timestamps, permisos, ownership (minúscula)
• -r — recursivo (directorios)
• -i ruta/clave — clave SSH específica
• -C — comprimir durante transferencia
• -l Kbps — limitar ancho de banda en Kbit/s
• -v / -vv / -vvv — verbosidad incremental
• -4 / -6 — forzar IPv4 o IPv6
• --exclude=patron — excluir archivos
• -o opciones — pasar opciones SSH (ej: -o StrictHostKeyChecking=no)

Lee también: Claves SSH ed25519: cómo generarlas bien si quieres entender mejor la criptografía detrás de la autenticación que usa SCP, o Hardening SSH en 2026: 10 cambios de seguridad si quieres blindar el servidor antes de exponer SCP a internet.

---

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux