OpenBSD Journal

OpenSSH turns Five.

Contributed by grey on from the get the candles dept.

Thanks to Jose Nazario for pointing out the following:

Sam Varghese of The Age writes about OpenSSH's fifth anniversary and Damien Miller in the following article: OpenSSH marks its fifth birthday

OpenSSH was first shipped with the 1999 winter OpenBSD 2.6 release. This article is rather timely as we're now ten releases later with the soon to be shipping OpenBSD 3.6.

In case you get prompted for registration, paranoid (or heavily spammed from other shady registration forms) folks may want to try bugmenot for help.

(Comments are closed)

  1. By Anthony ( on

    One thing about connection multiplexing... My firewall gives interactive SSH stuff priority over bulk transfers... given that packets must arrive in order, I assume the URG flag won't do any good. Still gold for logins inside my LAN though.

  2. By Anonymous Coward ( on

    Happy birthday OpenSSH!! May Telnet R.I.P.

    The only thing I would like from the OpenSSH package would be tab completion in the sftp client and probably a bit more bells and whistles in the sftp client would really be nice.

    Other than that, OpenSSH is great!

    1. By djm@ ( on

      I have patches for commandline history and editing in the sftp client, hopefully they (or ones like them) will make it in to the next release. IMO the biggest thing lacking from sftp is recursive transfers (e.g. "get -r foo/"), this is planned too (but my time is lacking).

      1. By Ed White ( on

        Damien, instead of recursive behaviour, that could be dangerous I would suggest to implement FTP mget and something like mput.

        1. By djm@ ( on

          We already support "get */*.gif" in sftp, but recursive operations (along with a compatible commandline) are essential to make it a scp replacement. The scp "protocol" needs to die.

          1. By Anthony ( on

            Why does scp need to die?

            I'm not sure if you're talking about the network protocol or the command line interface, but the command line interface is preferable to an FTP-like interface. To me at least.

            I would be indifferent if scp were replaced with a workalike with the same capabilities but a different back end.

            1. By Anonymous Coward ( on

              I too wouldn't want scp to die.

              For somethings it's usefull, although it does some funny things sometimes when you don't use it right which I guess would be expected (like duh! use it right bonehead). Yeah, it's a user error thing and I've been boneheaded enough to commit the errors.

              All the other suggestions for sftp have been pretty good though. I don't often recursively get full directories of files, but it would really be usefull. mput and mget would also be nice.

              Again, those are excellent suggestions. I hope someone much more talented than I can submit patches for those features. ;)

              1. By djm@ ( on

                I pretty clearly said that is the scp *protocol* needs to die and referred to the need to make the sftp commandline compatible, so don't worry.

            2. By Anonymous Coward ( on

              IMHO, rsync is preferrable to scp every time.

              The syntax is almost the same! You want to set RSYNC_RSH=ssh (or at compile time) and you are set. It doesn't output data by default, much like other file utils such as cp, but throw in a -vP.

              The biggest difference is that rsync automatically resumes broken transfers. Plus it has a lot of nice options for uid translation etc. It is much more powerful! Every newly installed system should include rsync!

            3. By RC ( on

              > the command line interface is preferable to an FTP-like interface.

              Only if you have a photographic memory, and always know the exact path and filename you want, and are a 100% perfect typist.

              I use scp quite a bit too, and it most certainly has it's place, but a good ftp interface beats it hands-down.

              The only thing that REALLY bugs be about scp is that special characters need to be double-escaped, if you will... For instance, if you have a space in a directory or filename you want to transfer, you have to put a backslash before the space, and put quotations marks around the whole thing. Alternatively, you can put single-quotes inside of double-quotes to accomplish the same thing, although you can't do that if you want to use wildcards. It's very difficult to keep straight, and entirely pointless, IMHO.

        2. By Mouring ( on

          Actually, recursive sftp support and recursive ftp support are two different birds. sftp server draft doesn't offer any "server side" support for recusion. Therefor all that code exists in the client only. So the sftp server won't be increasing in size.

          recursive put is easy. I've seen a few implementation. recursive get becomes harder since there is no server side assistances.

          - Ben

      2. By Matt Van Mater ( on

        I agree, the most lacking part in sftp would be a recursive transfer, only then followed by not having tab completion.

  3. By Anonymous Coward ( on

  4. By Anonymous Coward ( on

    Although this is a lame suggestion

    How 'bout another T-Shirt ?

  5. By Anonymous Coward ( on

    In my culture we celebrate birthdays by giving gifts to the birthday person. Am i correct in assuming the right way to do this for OpenSSH is to donate to the OpenBSD project?

    1. By Lennie ( on

      How about hardware...?:

      Or just buy t-shirts & CD's or donate money ofcourse. :-)


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]