Martin Pool's blog

Mail me RSS Bazaar distcc Canonical is hiring! flickr

secsh-filexfer

I've been reading about the IETF Secure Shell working group, which is basically the standardization effort for the program/protocol we now know as "ssh".

("SSH" is a trademark of "SSH Communications Security", Tatu Ylonen's company. They've granted a licence for people to have programs called ssh, but I think the standard is trying to move away from using the trademark towards "secure shell" or "secsh".)

In particular, the draft-ietf-secsh-filexfer-04 protocol draft looks like an extremely interesting solution for an rsync successor. Rather than inventing the protocol and program from scratch, it could build on secsh-filexfer and add delta-compression operations to the protocol, plus offering some programs for doing recursive/automatic transfers.

The protocol is not exactly as I would have done it, but it is remarkably close to the design that I and other people have been converging on: a pipelined sequence of reasonably simple file operations, running over a secure channel.

Another thing I recently discovered is why SSH has the "subsystem" mechanism -- at the moment the most popular is sftp, though there are others such as skermit. On Unix this maps into the server just executing an inetd-style server, so it's more or less equivalent to the client invoking ssh /usr/sbin/sftpd, much as rsync or CVS do. So why bother having a special mechanism rather than just invoking the server?

The reason is that on some systems such as Netware it is impossible to implement a shell over SSH: some systems don't have interactive shells, and others don't have the right pty or fifo mechanisms you'd need to do it properly. (Telnet on Windows has always been pretty flaky.) But if the server is invoked as an SSH subsystem, then the server can invoke it in some system-dependent way. You could for example implement sftpd as a loadable module or even a builtin on a non-Unix sshd, and it would be transparent to clients. The subsystem design basically only requires that the operating system be able to do TCP -- process models and IPC are implementation details. Very clever indeed.

posted Sat 21 Jun 2003 in /projects/superlifter | link

Copyright (C) 1999-2007 Martin Pool.