Comment by teddyh | Hacker News Reader

Comment by teddyh | Hacker News Reader

> Anyway, I designed SSH to replace both telnet (port 23) and ftp (port 21).

That sounds weird. Did SSH originally have file-copying capabilities? As I recall, the ssh command was written to be command-line compatible with rsh, not telnet, since rsh (and its companion rlogin) was what people were using at the time to log in over the network between local systems. The manual page for SSH still states this explicitly: “It is intended to replace rlogin and rsh […]”, and SSH from the start had (and still has) an rlogin replacement, "slogin". (Telnet was at the time only used for accessing remote, i.e. not-on-site, services, which did not necessarily imply shell access.) Anyway, the rsh and rlogin protocols use port 513 and 514, but no nearby ports seems to be unallocated. The story seems to be missing some details, or possibly be made up after the fact in lieu of a bad memory.

It seemed reasonable to me at the time to give port 22 to a better replacement for, and a spiritual successor to, Telnet, but the story seems odd for not mentioning rsh or rlogin at all.

> Did SSH originally have file-copying capabilities

ssh basically sets up a secure connection between two hosts, then forwards its standard input to the standard input of a program on the other side.

You can sort of simulate scp by something like:

cat my_file | ssh me@example.com "cat >my_remote_file"

tar -cf - ./somedir | ssh remote '(cd /whatever;tar -xvf -)'

I use that enough that I didn't need to look it up. Works the other direction as well. Was common with rsh before ssh existed.

It's not as efficient as rsync, but I can tell where files will end up without re-reading a man page.

tar -cf - ./somedir | ssh remote tar -xvf - -C /whatever

I mean, I'd encourage you to use && instead of ;...

I still wonder why `cd` doesn't have a form `cd dir command...`, as in `cd dir tar xf -`.

You could quite easily write a script that does this:

    #!/bin/sh
    cd $1
    shift
    exec "$@"

It's a shame "in" is a reserved word, because that'd be a good name for it. Maybe "cde" for "cd-exec":

    tar c files | ssh dest cde /some/dir tar x

Mine is called cdx and includes 'env' functionality and a bit more. (https://github.com/apk/c-utils/blob/master/aenv.c)

The form I usually use is (cd TARGET && COMMAND), including the parentheses to make it a subshell. That seems close enough to not be worth adding features to something as simple as cd, given the basic shell philosophy of composability.

Rlogin is mentioned. Read the first email in the article - the one to IANA:

"I have written a program to securely log from one machine into another over an insecure network. It provides major improvements in security and functionality over existing telnet and rlogin protocols and implementations."

It still does have file-copying capabilities. See scp(1).

And don't forget sftp!

Sftp was not part of the original SSH program, IIRC.

I agree. I first started using SSH in 1996 or so, building it from source on a Linux Slackware system (which didn't even have ELF binaries!)

sftp didn't appear for a few years later.

I remember porting my system from a.out to elf binaries. Manually. Learned a lot though.

Scp was, according to its manual page, based on rcp (part of the rsh/rlogin set of programs): “scp is based on the rcp program”.

Sure, but scp uses the same port as ssh so the underlying protocol has to deal with both terminal and file copying commands.

Well, yes, exactly: rsh, rlogin and rcp were often considered together, as they both used the same access control - /etc/hosts.equiv. So it's not that surprising that ssh, slogin and scp came together as a replacement set.

Reply on news.ycombinator.com