2

I am often working remotely with SSH and SFTP. The latter being basically a file copy protocol running over SSH, I am wondering whether there is a reason those two tools have not been integrated yet except from "nobody could be bothered to do it so far". With "integration" I mean to say that there should be some way of changing the SSH mode to SFTP and back in the same session. Like this for example:

Log in with SSH:

$ ssh -i privkey foouser@barserver.example.org
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

We want to replace index.html, so apply some magic keyboard combination to switch mode:

sftp> put index.html

Back to SSH mode using another keyboard combination:

-bash-4.1$ md5sum index.html
dd208743fa38dd55ec21c1ed75fa035c

Sounds very practical and obviates the need to do copy-paste or to have two sessions open. Would implementing this demand heavy changes to the SSH protocol?

migrated from programmers.stackexchange.com Nov 18 '14 at 13:27

This question came from our site for professionals, academics, and students working within the systems development life cycle.

  • 3
    The Unix Philosophy – Oded Nov 18 '14 at 11:50
  • 1
    sshfs – aragaer Nov 18 '14 at 12:04
  • 1
    Also !command in sftp. – aragaer Nov 18 '14 at 12:06
  • The SSH transport format is channel-based, so it probably wouldn't require very extensive modifications to the protocol. It's perfectly possible that there are clients out there which allow this already. I suppose the real question is, would it be enough of a savings to warrant the time required to implement, test, document, debug and maintain the feature, in favor of some other feature? – a CVn Nov 18 '14 at 13:54
  • @Oded Not really, as the "sftp" functionality in the deamon part sshd of OpenSSH is currently provided both by a "subsystem" (a separate executable referenced from the sshd config file) and integrated in the sshd daemon directly (which is useful if you want sshd to chroot a user without having to ensure the sftp executable be visible from the chroot jail). So all the code is there, in one server program. It's just the client that comes in two separate commands: ssh and sftp. – David Tonhofer Nov 18 '14 at 18:00
2

Backward Compatibility!

ftp has been around in some form or other since 1971. It became the standard IP file transfer protocol in 1980. "sftp" is simply an ftp protocol that uses encryption when transmitting data over the network but is otherwise identical to the "ftp" protocol. This allows millions of existing scripts and procedures to take advantage of the improved security with minimum change.

ssh -- secure shell protocol is designed to run shell commands over a secure network. The various network utility commands that come with ssh are modeled on the familiar (to shell scripters) Bourne shell commands hence "scp" syntax is loosely based on the unix "cp" syntax.

  • 3
    James, you write: "sftp" is simply an ftp protocol that uses encryption when transmitting data over the network but is otherwise identical to the "ftp" protocol. This is not true. sftp is a filetransfer/filemanipulation implementation on top of the SSH protocol. It is quite unlike FTP, in particular, it has no separate control and data network connections as FTP does and which are a plague to administer and firewall-code for. You may confuse this with FTPS. – David Tonhofer Nov 18 '14 at 17:56
  • @david Tonhofer -- thanks for clarifying. The main point was that sftp command syntax is very like ftp, and, its this command line compatibility is the main reason for using sftp over scp. – James Anderson Nov 19 '14 at 7:06
0

I'd say that all the FTP mechanics of sessions, separate data and control connections going in opposite directions, current directories, etc would be hard and pointless to implement inside ssh. Copying could just reuse the connection and and the fact it is running a shell on the other side (which it not always does).

For quick file copying, you can just reuse the existing connection. Let's assume you're using OpenSSH.

Make a normal ssh connection, and, when you need to copy a file, use another terminal window / tmux window / tty to issue an scp command.

If you have ControlMaster set (globally or for a particular host group) in your ~/.ssh/config, scp will reuse your existing connection and will not ask for passwords or waste time reconnecting.

The only problem is that the scp will not attach to your existing session and reuse the current directory of that shell. But this is not always possible anyway: imagine that your remote shell is already running a different process (tmux, mc, tail -f, etc). So you have to write it in full: scp index.html hemote.host:path/to/www/. Usually it's not hard to copy the path from the remote window.

Unfortunately, ~Ctrl+Z or ~& won't work for multiplexed sessions, so if all you have is a single old VT-220, you should have run tmux or screen beforehand.

Same would apply to rsync or sshfs or even sftp that support different models of sending data but could as well share the connection.

  • Thanks, but the sftp command does exist and does all of scp and even more. The question is, why is it separate from ssh. As for FTP, no-one is going to re-implement that on top of SSH for sure, there have been a number of encrypted FTP protocols, with FTPS being the one that won out it seems. – David Tonhofer Nov 18 '14 at 18:12
  • My point is that merging sftp and ssh would be a significant pain, due to very different models of most everything. What they share is just the encryption layer. – 9000 Nov 18 '14 at 19:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.