Um comando scp que funcionou num script durante anos pode falhar num cliente atual com um erro de caminho que nada tem a ver com o túnel. A VPN transportou os bytes; o cliente pediu ao servidor um nome que o servidor não conseguiu resolver. O scp atual do OpenSSH transfere por SFTP por predefinição, e o SFTP não faz expansão ao estilo da shell como o protocolo antigo. Seguir o comando a partir da sua própria conta para fora mostra onde o caminho é realmente interpretado.

Comece pela conta e depois pelo diretório onde ela pode escrever

Os dois pontos separam dois espaços de nomes, e só o lado esquerdo pertence à máquina onde está a escrever. Tudo o que vem depois é resolvido pelo servidor, sob a conta com que se autenticou, dentro da vista do sistema de ficheiros que essa conta tem. Confirme ambos antes de compor o comando, porque um caminho correto para o administrador não é automaticamente correto para o utilizador da transferência. Essa diferença é a origem da maioria dos erros de permissões que parecem falhas de rede.

Pergunte ao servidor pela vista dele: ssh [email protected] pwd e ssh [email protected] ls -ld /srv/archive. Se o segundo comando indicar permissão negada, o túnel está bem e o caminho é inutilizável para essa conta. Corrija a propriedade ou escolha outro destino em vez de alargar permissões para que a transferência possa continuar.

Uma configuração restrita de SFTP pode apresentar um chroot como raiz do sistema de ficheiros. Dentro dessa vista um caminho absoluto é absoluto dentro do chroot, que não é o mesmo local que o administrador vê no anfitrião.

Nomeie explicitamente os dois lados dos dois pontos

Um envio deve indicar o nome do ficheiro remoto em vez de assumir que o nome base local será aceitável do outro lado.

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

Um download deve indicar o destino local exatamente pelo mesmo motivo. Os dois espaços de nomes são independentes, e um script que assume que coincidem quebra na primeira vez que a árvore remota usa uma disposição diferente.

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

Evite ~otheruser num script mantido. Expandir o diretório pessoal de outra conta era uma funcionalidade da shell remota, e um servidor SFTP pode não implementar a extensão que a emula. Escreva o caminho absoluto que a conta realmente pode abrir, e ponha entre aspas os caminhos locais com espaços em vez de copiar camadas de aspas escritas para uma shell no servidor.

Saiba que protocolo o seu scp realmente usa

Desde o OpenSSH 9.0 o cliente usa SFTP por predefinição, e as distribuições adotam ou retroportam esse comportamento segundo o seu próprio calendário. A cadeia de versão diz o que o cliente pretende, mas uma compilação do fornecedor pode diferir do upstream, por isso verifique o cliente que realmente executa: ssh -V.

Os dois protocolos resolvem nomes de forma diferente. O SCP antigo pede à shell do utilizador remoto que expanda o caminho, por isso os curingas e as tiles são tratados por essa shell com as suas próprias regras. O SFTP emite operações de transferência de ficheiros, por isso um curinga ou é expandido pelo cliente ou não é expandido de todo. Ambos viajam dentro do SSH para a mesma máquina, e é por isso que um anfitrião pode comportar-se de forma diferente com dois clientes.

scp -v imprime o subsistema que solicita, e uma linha de subsistema sftp confirma que o caminho moderno está a ser usado. scp -O força o protocolo antigo onde é suportado e realmente necessário, e traz consigo as suas próprias regras de aspas. Não é uma opção de VPN, não é uma forma de ativar algo no servidor e não é razão para relaxar a verificação da chave do anfitrião.

Teste o caminho antes de o script depender dele

Um problema de caminho surge no pior momento possível, numa tarefa automatizada à noite sem ninguém a ver. Prove o destino primeiro com um ficheiro pequeno e a conta exata que a tarefa usa, e mantenha esse comando de teste junto à definição da tarefa. Se o teste precisar de outra conta ou de outro diretório, a tarefa também precisará.

Verifique também o lado do servidor. grep -i subsystem /etc/ssh/sshd_config mostra se está configurado um subsistema SFTP, e sftp -b /dev/null [email protected] só termina com sucesso quando esse subsistema responde. Um anfitrião que aceita inícios de sessão SSH mas não tem subsistema falha em todas as transferências modernas embora pareça perfeitamente saudável num teste de início de sessão.

Anote a versão do cliente, o protocolo em uso e o caminho remoto absoluto nas notas da tarefa. Quando a próxima atualização mudar um valor predefinido, essa nota é a diferença entre uma correção de cinco minutos e uma tarde de suposições.

Artigos relacionados