Existe uma razão para o ssh e o sftp serem tão desintegrados?

Question

Frequentemente estou trabalhando remotamente com SSH e SFTP. Sendo este último basicamente um protocolo de cópia de arquivos executado em SSH, estou me perguntando se existe uma razão para essas duas ferramentas não terem sido integradas, exceto pelo fato de que "ninguém poderia se incomodar em fazê-lo até agora". Com a "integração", quero dizer que deve haver alguma maneira de alterar o modo SSH para SFTP e voltar na mesma sessão. Assim, por exemplo:

Faça o login com o SSH:

$ ssh -i privkey [email protected]
Last login: Tue Nov 18 10:47:25 2014
-bash-4.1$ ls
cgi-bin  error  html  icons  manual
-bash-4.1$ cd html
-bash-4.1$ ls
index.html
-bash-4.1$ md5sum index.html
ad7c5e1ed76c2d4efd6613315b4d1411

Queremos substituir o index.html, portanto, aplique uma combinação de teclado mágico no modo de troca:

sftp> put index.html

Voltar ao modo SSH usando outra combinação de teclado:

-bash-4.1$ md5sum index.html
dd208743fa38dd55ec21c1ed75fa035c

Soa muito prático e elimina a necessidade de copiar e colar ou abrir duas sessões. A implementação dessa demanda exigiria mudanças pesadas no protocolo SSH?

    

Answer 1

Compatibilidade retroativa!

O ftp existe desde 1971. Ele se tornou o protocolo padrão de transferência de arquivos IP em 1980. "sftp" é simplesmente um protocolo FTP que usa criptografia ao transmitir dados pela rede, mas é idêntico ao " ftp "protocolo. Isso permite que milhões de scripts e procedimentos existentes aproveitem a segurança aprimorada com o mínimo de alterações.

O protocolo shell ssh-secure é projetado para executar comandos do shell em uma rede segura. Os vários comandos utilitários de rede que vêm com o ssh são modelados nos comandos de shell Bourne familiares (para shell scripts), portanto a sintaxe "scp" é vagamente baseada na sintaxe "cp" do unix.

    

Answer 2

Eu diria que toda a mecânica de sessões de FTP, separar dados e controlar conexões indo em direções opostas, diretórios atuais, etc, seria difícil e sem sentido implementar dentro do ssh. A cópia poderia apenas reutilizar a conexão e o fato de estar executando um shell no outro lado (o que nem sempre acontece).

Para a cópia rápida de arquivos, você pode apenas reutilizar a conexão existente. Vamos supor que você esteja usando o OpenSSH.

Faça uma conexão ssh normal e, quando precisar copiar um arquivo, use outra janela de terminal / janela tmux / tty para emitir um comando scp .

Se você tiver ControlMaster set (globalmente ou para um determinado grupo de hosts) em seu ~/.ssh/config , scp reutilizará sua conexão existente e não solicitará senhas nem perderá tempo reconectando.

O único problema é que o scp não se anexará à sua sessão existente e reutilizará o diretório atual desse shell. Mas isso nem sempre é possível: imagine que seu shell remoto já esteja executando um processo diferente ( tmux , mc , tail -f , etc). Então você tem que escrever na íntegra: scp index.html hemote.host:path/to/www/ . Geralmente não é difícil copiar o caminho da janela remota.

Infelizmente, ~ Ctrl + Z ou ~ & não funcionará para sessões multiplexadas, então se tudo o que você tem é um único VT-220 antigo, você deve ter executado tmux ou screen de antemão.

O mesmo se aplica a rsync ou sshfs ou mesmo sftp que suportem diferentes modelos de envio de dados, mas que também possam compartilhar a conexão.