scp su SFTP: scrivere percorsi remoti che si risolvono davvero

Un comando scp che ha funzionato in uno script per anni può fallire su un client attuale con un errore di percorso che non ha nulla a che vedere con il tunnel. La VPN ha trasportato i byte; il client ha chiesto al server un nome che il server non è riuscito a risolvere. Lo scp attuale di OpenSSH trasferisce via SFTP per impostazione predefinita, e SFTP non esegue espansioni in stile shell come faceva il vecchio protocollo. Ripercorrere il comando dal proprio account verso l'esterno mostra dove il percorso viene davvero interpretato.

Partite dall'account, poi dalla directory in cui può scrivere

I due punti separano due spazi dei nomi, e solo il lato sinistro appartiene alla macchina su cui state digitando. Tutto ciò che segue viene risolto dal server, sotto l'account con cui vi siete autenticati, all'interno della vista del file system che quell'account possiede. Confermate entrambi prima di comporre il comando, perché un percorso corretto per l'amministratore non è automaticamente corretto per l'utente del trasferimento. Questa differenza è l'origine della maggior parte degli errori di autorizzazione che sembrano guasti di rete.

Chiedete al server la sua vista: ssh [email protected] pwd e ssh [email protected] ls -ld /srv/archive. Se il secondo comando segnala permesso negato, il tunnel è a posto e il percorso è inutilizzabile per quell'account. Correggete la proprietà o scegliete un'altra destinazione invece di ampliare i permessi perché il trasferimento possa procedere.

Una configurazione SFTP limitata può presentare un chroot come radice del file system. Dentro quella vista un percorso assoluto è assoluto all'interno del chroot, che non è la stessa posizione che l'amministratore vede sull'host.

Nominate esplicitamente entrambi i lati dei due punti

Un caricamento dovrebbe indicare il nome del file remoto invece di presumere che il nome base locale sarà accettabile dall'altra parte.

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

Un download dovrebbe indicare la destinazione locale esattamente per lo stesso motivo. I due spazi dei nomi sono indipendenti, e uno script che presume che coincidano si rompe la prima volta che l'albero remoto usa una disposizione diversa.

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

Evitate ~otheruser in uno script mantenuto. Espandere la directory home di un altro account era una funzione della shell remota, e un server SFTP potrebbe non implementare l'estensione che la emula. Scrivete il percorso assoluto che l'account può davvero aprire, e mettete tra virgolette i percorsi locali con spazi invece di copiare livelli di virgolette scritti per una shell sul server.

Sappiate quale protocollo usa davvero il vostro scp

Da OpenSSH 9.0 il client usa SFTP per impostazione predefinita, e le distribuzioni adottano o retroportano questo comportamento secondo il proprio calendario. La stringa di versione dice cosa intende fare il client, ma una build del fornitore può differire dall'upstream, quindi controllate il client che eseguite davvero: ssh -V.

I due protocolli risolvono i nomi in modo diverso. Il vecchio SCP chiede alla shell dell'utente remoto di espandere il percorso, quindi i caratteri jolly e le tilde sono gestiti da quella shell con le sue regole. SFTP emette invece operazioni di trasferimento file, quindi un carattere jolly o viene espanso dal client o non viene espanso affatto. Entrambi viaggiano dentro SSH verso la stessa macchina, ed è per questo che un host può comportarsi diversamente con due client.

scp -v stampa il sottosistema che richiede, e una riga di sottosistema sftp conferma che il percorso moderno è in uso. scp -O forza il vecchio protocollo dove è supportato e davvero necessario, e riporta con sé le sue regole di quoting. Non è un'opzione VPN, non è un modo per abilitare qualcosa sul server e non è una ragione per allentare il controllo della chiave dell'host.

Provate il percorso prima che lo script vi si affidi

Un problema di percorso emerge nel momento peggiore possibile, in un'attività automatizzata di notte senza nessuno che guardi. Dimostrate prima la destinazione con un file piccolo e l'account esatto che usa l'attività, e tenete quel comando di prova accanto alla definizione dell'attività. Se la prova richiede un altro account o un'altra directory, anche l'attività ne avrà bisogno.

Controllate anche il lato server. grep -i subsystem /etc/ssh/sshd_config mostra se è configurato un sottosistema SFTP, e sftp -b /dev/null [email protected] termina con successo solo quando quel sottosistema risponde. Un host che accetta accessi SSH ma non ha sottosistemi fallisce ogni trasferimento moderno pur sembrando perfettamente sano in una prova di accesso.

Annotate la versione del client, il protocollo in uso e il percorso remoto assoluto nelle note dell'attività. Quando il prossimo aggiornamento cambierà un valore predefinito, quella nota è la differenza tra una correzione di cinque minuti e un pomeriggio di supposizioni.