scp sobre SFTP: escribir rutas remotas que realmente se resuelven

Un comando scp que funcionó en un script durante años puede fallar en un cliente actual con un error de ruta que nada tiene que ver con el túnel. La VPN transportó los bytes; el cliente pidió al servidor un nombre que el servidor no pudo resolver. El scp actual de OpenSSH transfiere por SFTP de forma predeterminada, y SFTP no hace expansión al estilo de shell como hacía el protocolo antiguo. Recorrer el comando desde su propia cuenta hacia afuera muestra dónde se interpreta realmente la ruta.

Empiece por la cuenta y luego por el directorio en el que puede escribir

Los dos puntos separan dos espacios de nombres, y solo el lado izquierdo pertenece a la máquina en la que escribe. Todo lo que sigue lo resuelve el servidor, bajo la cuenta con la que se autenticó, dentro de la vista del sistema de archivos que tenga esa cuenta. Confirme ambos antes de componer el comando, porque una ruta correcta para el administrador no es automáticamente correcta para el usuario de la transferencia. Esa diferencia es el origen de la mayoría de los errores de permisos que parecen fallos de red.

Pregunte al servidor por su propia vista: ssh [email protected] pwd y ssh [email protected] ls -ld /srv/archive. Si el segundo comando informa permiso denegado, el túnel está bien y la ruta no es utilizable para esa cuenta. Corrija la propiedad o elija otro destino en lugar de ampliar permisos para que la transferencia pueda continuar.

Una configuración restringida de SFTP puede presentar un chroot como raíz del sistema de archivos. Dentro de esa vista una ruta absoluta es absoluta dentro del chroot, que no es la misma ubicación que ve el administrador en el host.

Nombre explícitamente ambos lados de los dos puntos

Una carga debería indicar el nombre del archivo remoto en lugar de suponer que el nombre base local será aceptable en el otro extremo.

scp q3-invoice.csv [email protected]:/home/transfer/drop/q3-invoice.csv

Una descarga debería indicar el destino local exactamente por la misma razón. Los dos espacios de nombres son independientes, y un script que supone que coinciden se rompe la primera vez que el árbol remoto usa una disposición diferente.

scp [email protected]:/srv/archive/2026-q3.csv ./2026-q3.csv

Evite ~otheruser en un script que se mantiene. Expandir el directorio personal de otra cuenta era una función del shell remoto, y un servidor SFTP puede no implementar la extensión que lo emula. Escriba la ruta absoluta que la cuenta puede abrir realmente, y entrecomille las rutas locales con espacios en lugar de copiar capas de comillas escritas para un shell en el servidor.

Sepa qué protocolo usa realmente su scp

Desde OpenSSH 9.0 el cliente usa SFTP de forma predeterminada, y las distribuciones adoptan o retroportan ese comportamiento según su propio calendario. La cadena de versión dice qué pretende el cliente, pero una compilación de proveedor puede diferir del upstream, así que compruebe el cliente que realmente ejecuta: ssh -V.

Los dos protocolos resuelven nombres de forma distinta. El SCP antiguo pide al shell del usuario remoto que expanda la ruta, así que los comodines y las tildes los maneja ese shell con sus propias reglas. SFTP emite operaciones de transferencia de archivos, así que un comodín o lo expande el cliente o no se expande en absoluto. Ambos viajan dentro de SSH a la misma máquina, y por eso un host puede comportarse distinto bajo dos clientes.

scp -v imprime el subsistema que solicita, y una línea de subsistema sftp confirma que se usa la ruta moderna. scp -O fuerza el protocolo antiguo donde está soportado y realmente se requiere, y trae consigo sus propias reglas de comillas. No es una opción de VPN, no es una forma de habilitar algo en el servidor y no es una razón para relajar la comprobación de la clave del host.

Pruebe la ruta antes de que el script dependa de ella

Un problema de ruta aparece en el peor momento posible, en una tarea automatizada de noche sin nadie mirando. Demuestre primero el destino con un archivo pequeño y la cuenta exacta que usa la tarea, y mantenga ese comando de prueba junto a la definición de la tarea. Si la prueba necesita otra cuenta u otro directorio, la tarea también necesitará uno.

Compruebe también el lado del servidor. grep -i subsystem /etc/ssh/sshd_config muestra si hay un subsistema SFTP configurado, y sftp -b /dev/null [email protected] termina con éxito solo cuando ese subsistema responde. Un host que acepta inicios de sesión SSH pero no tiene subsistema falla en toda transferencia moderna mientras parece perfectamente sano en una prueba de inicio de sesión.

Anote la versión del cliente, el protocolo en uso y la ruta remota absoluta en las notas de la tarea. Cuando la próxima actualización cambie un valor predeterminado, esa nota es la diferencia entre una corrección de cinco minutos y una tarde de conjeturas.