Slashdot Mirror

Exactly what did i say that was bullshit?

The default configuration on modern versions (since 7.0) is to only allow root logins with keys, see:
https://www.openssh.com/txt/re...

I never said it wasn't configurable, i said password root login is not enabled by default.

Untrusted X11 forwarding was meant to be a way to allow logins to unknown or insecure systems. It generates a cookie with xauth and uses the Security extension to limit what the remote client is allowed to do. But this is widely considered to be not useful, because the Security extension uses an arbitrary and limited access control policy, which results in a lot of applications not working correctly and what is really a false sense of security. This is true even today; I rebuilt XWin with Security enabled and 'ssh -X' into my linux VM, and got BadAccess errors from *any* GTK2 program. More on this subject:

http://www.openssh.com/faq.html#3.13
http://www.nsa.gov/selinuX/papers/x11/x93.html

Given the limited usefulness of untrusted X11 forwarding, *upstream* has disabled it by default in favour of other security models.

Btw, since the extension is disabled/not present the ssh -X falls back to ssh -Y (untrusted forwarding) on most systems.

Jesus Christ! Do we have to explain the basics to you?!

Security by obscurity is bunk. You should know this.

You have heard about the Cathedral and the Bazaar, right?

Some of the most secure things are out in the open, for everyone to see.

OpenBSD and LibreSSL and OpenSSH are some of the most secure, bug-free software ever developed, and their code is out in the open. They're so secure because they're developed openly!

If you really care about stuff like "a free and unrestricted internet", and want to ensure the safety and future of "free human communication", then just donate to OpenBSD. You'll be supporting a group of people who take security very seriously (their software is among the most secure there is), who know all about freedom (their preferred software license is about as free as you can get), and who provide some of the most critical Internet communication software there is (OpenSSH, LibreSSL, and OpenSMTPD). Making a donation to OpenBSD is a great way to meet the criteria that you set forth.

What is this, 1980? There's no Internet that everybody's using?

Look, it's not 1980. It's 2015. You don't have to "keep it local" in order to see how your money is being used.

Donate to OpenBSD, and you'll be able to follow along as their already-superb software continues to get even better and better. Not only would you be supporting the development of a free and extraordinarily secure operating system, but the people responsible for OpenBSD are also responsible for tremendously important software like OpenSSH and LibreSSL. This is some of the most important open source software around. Since it's open source, we can all inspect its code to see what they're doing with our donations.

The OpenBSD developers don't fuck around. These are serious people, creating seriously secure, reliable and useful open source software products. Your donation to them doesn't just help a few people in your vicinity. Your contributions to OpenBSD helps out almost the entire world. The software they work on is just that damn important!

So do the only sensible thing there is to do: donate to OpenBSD.

Take a look at FreeBSD Gnome, for example. I am sure that their patches to make Gnome portable again flow back upstream.

Perhaps, but this is exactly what I said; only the minimal effort to make the DE's run on BSD is made by BSD developers; when it comes to making the actual DE there seems to be no BSD developers helping out. In short, BSD developers aren't pulling their share of the load when it comes to DE development.

OpenSSH is portable. This is the difference between Linux and BSD developers. [snip: the usual anti-Linux ranting]. most Unices/BSDs already have the solutions for the problems and why should they accept something that has to be ported with a lot of effort? It is only being done with things that are worth to port.

Exactly, this is why DE's like KDE and Gnome shouldn't accept BSD patches anymore, but just make the BSD developers maintain the DE's in their own source trees, just like OpenSSH. If it is worth for BSD to maintain them, then they can do it, if not, then why bother Linux developers to make it BSD compatible.

As it is now, BSD is simply dragging Linux DE development down without the BSD developers contributing anything instead. At some point this has to stop; either the BSD community starts contributing, or the Linux community will stop working for free.

Take a look at FreeBSD Gnome, for example. I am sure that their patches to make Gnome portable again flow back upstream.

When someone develops an desktop environment that does not restrict users to Linux, you should expect from them to make the system portable. The work to make it run should be minimal.

Wayland is being ported to FreeBSD, too. It is a bit useless though, because of Linuxisms in libinput and Weston.

OpenSSH is portable. This is the difference between Linux and BSD developers. BSD developers stick to the Unix concepts and portability has a high value here. Linux developers invent (mostly already existing) solutions by themselves, multiple times, multiple times in a wrong way and mostly for themselves, because... most Unices/BSDs already have the solutions for the problems and why should they accept something that has to be ported with a lot of effort? It is only being done with things that are worth to port.

The Git address of OpenSSH portable has also been spuriously set to "anongit.mindrot.org".

Development of portable versions of other OpenBSD projects doesn't appear to have suffered.[1] What makes you think LibreSSL will be any different?

[1] The OpenBSD Foundation:
OpenSSH
OpenNTPD
OpenSMTPD

Not necessarily. It looks like they're removing what they can't support, such as VMS, Netware and OS/2. The few people that care can still use the original OpenSSL code.

I'd expect them to ensure it support the hardware platforms OpenBSD supports at the very least. Then, if they go the "portable" route like they did for OpenSSH, support for the other Unix and Unix-like systems.

http://www.openssh.com/portable.html

More power to them.

You mean like the trojan that was in OpenSSH for 2 days?

FTFY.

Additionally isn't Google a Linux vendor these days? Seems a bit disingenuous to still say

no Commercial Unix or Linux vendor has ever given our project [openssh] a cent

It is never a happy occasion to realize that a not-for-profit group, no matter how destitute or successful, is undeserving of charitable donations. And just last week I had such an unhappy realization. I wanted to donate a sizable sum of money to the OpenBSD Foundation for development of the OpeBSD operating system and other related projects.

My uncle, an old Unix graybeard from the Seventies, devoted his retirement and considerable savings to teaching inner-city youth about computers and programming. He recently passed away and left instructions in his will that I donate money, in the amount of US $100,000, to the most meritorious Free, Unix-like operating system as according to my own research into the matter.

I immediately looked at OpenBSD and began to review its technical merits, of which there are many. Despite lacking serious symmetric multi-processing support and drivers for recent graphics hardware, OpenBSD security and code-auditing are second to none. One only has to take a look at the bevy of routers that ship with OpenBSD to know how many people successfully depend on it everyday.

The OpenBSD Foundation is also behind several software packages widely adopted in other operating systems, such as OpenBGPD, OpenCVS, OpenNTPD, and OpenSSH. OpenSSH, for instance, is what allows clueless Mac users to remotely log into their systems safely, blissfully unaware of hackers.

After looking at the technical merits of OpenBSD and related projects, I owed it to the memory of my uncle to check out the history of the people behind it all. But that's when I ran into some interesting decisions regarding OpenBSD advocacy and funding made my OpenBSD's lead developer, Theo de Raadt.

In 2003, Mr. de Raadt trash-talked the United States military and its various aid projects for the Iraqi people. But at the time, OpenBSD was receiving a multi-million dollar grant from the United States Department of Defense. After the interview was published the DOD cancelled funding, which left several OpenBSD projects in limbo for quite some time thereafter.

This is just one of the more public instances of Mr. de Raadt sharing unpopular personal opinions while acting as OpenBSD's public advocate and costing the project considerable time and money. And, unfortunately, there are others.

Another time, Mr. de Raadt visited his native South Africa to receive a donation from a wealthy politician but unexpectedly refused it at the podium, instead making a speech in which he equated the use of non-Free graphics drivers with Apartheid. Mr. de Raadt left without the check but later claimed to have won an important moral victory.

Mr. de Raadt himself is at the root of the problem, but here I can't really separate the man from the project; Theo de Raadt is OpenBSD. So donating toward OpenBSD's goals means handing over money to this crackpot activist, if he would even accept it. That's too bad because OpenBSD would be further ahead without these sorts of megalomaniacal antics.

Digging even further back in time, it's clear that this pattern of behavior is nothing new. Theo de Raadt was one of the incipient developers of NetBSD, but harass[ed] and abuse[d] both users and developers of NetBSD. His colleagues subsequently locked him out of the project, de Raadt forked OpenBSD, and the rest is history.

After reviewing these facts, it is clear that I will fail to honor my uncle's memory and all of the hard work he did in life by donating to OpenBSD. If I wanted to dishonor him, maybe. And I find it highly likely that Theo de Raadt

Apple absolutely does care what you do with the iPhone. That's why they've updated the ROM in newer 3Gs models to prevent jailbreaking.

Gee, I hope that the OpenSSH guys don't have the gall to forcefully close this valuable way for others to operate your jailbroken iPhone for you.

What the blazes are you talking about, man? OpenSSH allows the user to use ssh and sftp in place of telnet and ftp. Thus, it specifically protects users from others seeing their passwords and other information. The problem with the way this was implemented on the iPhone is (according to the information about this hack) that it sets a default password for you, and if you don't change it, anyone who knows that default password can get in.

Not wanting to troll but, you know, if openssh was GPL licensed said commercial vendors would have to release the source for openssh with their products, including any modifications they made. The project could also offer LGPL or BSD licensed versions in exchange for cold, hard, cash.

Instead they do the noble thing and release their hard work without strings attached. They understand the alternatives but actively choose to stick with a license that doesn't childishly punish those who cannot or won't return the favor. They do what they do not to "stick it" to corporations but rather because they love to code and love when their code is used to improve peoples' lives. They even love it when somebody is able to take what they've done and build off of it or incorporate it into a product. It's a matter of love, and love must be given without strings and viral conditions. It's true charity, and charity is for the giver as much as the receiver. It's the BSD philosophy, and it's not often understand by the GNU herd. But that's okay, because the software we write is for them, too. And we love it even if they don't understand why.

Thanks OpenBSD. You're awesome. I hope a lot of people today make good use of this link.

The openssh web page says:

Please take note of our Who uses it page, which list just some of the vendors who incorporate OpenSSH into their own products -- as a critically important security / access feature -- instead of writing their own SSH implementation or purchasing one from another vendor. This list specifically includes companies like Cisco, Juniper, Apple, Red Hat, and Novell; but probably includes almost all router, switch or unix-like operating system vendors. In the 10 years since the inception of the OpenSSH project, these companies have contributed not even a dime of thanks in support of the OpenSSH project (despite numerous requests).

Not wanting to troll but, you know, if openssh was GPL licensed said commercial vendors would have to release the source for openssh with their products, including any modifications they made. The project could also offer LGPL or BSD licensed versions in exchange for cold, hard, cash.

Two additions to this:
# sshd -V
will tell you the version of your server (which may or may not be the same as your client version, depending on the packaging habits of your distro maintainers etc.)

Furthermore, the fix for this vulnerability was included in Version 5.2 of OpenSSH, so the grandparent poster could still be vulnerable. The article's mention of version 4.7 is somewhat misleading in this respect.

I think it is all below 5.2 according to http://openssh.com/security.html.

From the url:

# OpenSSH prior to version 5.2 is vulnerable to the protocol weakness described in CPNI-957037 "Plaintext Recovery Attack Against SSH". However, based on the limited information available it appears that this described attack is infeasible in most circumstances. For more information please refer to the cbc.adv advisory and the OpenSSH 5.2 release notes.

# Portable OpenSSH 5.1 and newer are not vulnerable to the X11UseLocalhost=no hijacking attack on HP/UX (and possibly other systems) described in the OpenSSH 5.1 release notes.

# OpenSSH 5.0 and newer are not vulnerable to the X11 hijacking attack described in CVE-2008-1483 and the OpenSSH 5.0 release notes.

Not exactly that helpfull however when I check my machine:
$ rpm -q openssh
openssh-5.1p1-3.fc10.x86_64

So I should be ok - err maybe.

Basically only CBC is vulnerable, so they prefer others. Also they now read the maximum size before returning an error. There still is a very slight information leak from timing analysis but it would make the chances much much smaller, to the point that it is now an infeasible attack:

http://www.openssh.com/txt/release-5.2

Security:

  * This release changes the default cipher order to prefer the AES CTR
      modes and the revised "arcfour256" mode to CBC mode ciphers that are
      susceptible to CPNI-957037 "Plaintext Recovery Attack Against SSH".

  * This release also adds countermeasures to mitigate CPNI-957037-style
      attacks against the SSH protocol's use of CBC-mode ciphers. Upon
      detection of an invalid packet length or Message Authentication
      Code, ssh/sshd will continue reading up to the maximum supported
      packet length rather than immediately terminating the connection.
      This eliminates most of the known differences in behaviour that
      leaked information about the plaintext of injected data which formed
      the basis of this attack. We believe that these attacks are rendered
      infeasible by these changes.

I think it is all below 5.2 according to http://openssh.com/security.html.

This flaw was published in Nov 2008 with simple configuration fix, and OpenSSH released a default fixed version in March 2009.
Also, this attack gives only 4 bytes of unencrypted output after crashing your session many thousands of times, which is sure to be noticed. If you were repeating the exact same network traffic in millions of SSH sessions, an attacker might get something interesting after weeks of crashing your sessions. It's just one of the lamest exploits I've seen, worth mitigating eventually, but not worth all the press it's getting, especially 6 months after release...
The fix is simple, just use CTR mode encryption instead of CBC, or upgrade to OpenSSH 5.2 or later.
For more details go to the OpenSSH security page.

Don't know about TrueCrypt, but OpenSSH is developed by Canadians and Germans. Pretty sure the US can't force them to get a license.

What about TrueCrypt, do they need a license as well? How about OpenSSH? The encryption horse has long since left the barn and any attempts to close the gate now are just security theatre. The real challenges going forward are key management and security at the endpoints.

I was talking about setting up a wifi hot spot. SSH is definitely dependent on SSL/TLS, but doesn't use certificates. Look for "For many of its cryptography features, OpenSSH relies on the non-GPL'd OpenSSL library...."

Kerberos uses a dual-key system similar to SSL, but replaces the Certificate Authority in realtime.

The copyright holder is still the copyright holder. He/she can remove the license whenever he/she wants.

While that is true going forward, it does not affect versions of the software that have already been released under the GPL. The best (or at least most well-known) example of this is SSH. SSH is not proprietary software, but it was originally released under a free license. When SSH was taken private, the OpenSSH project took the last free version of SSH 1.x source code, cleaned it up, made it portable, added features (including SSH 2 support and SFTP), and most importantly, kept it Free.

For more info, see the OpenSSHsite.

It's also worth noting that OpenSSH today is far more popular than its proprietary cousin, so his attempt to revoke the GPL on already released versions of his project is not only doomed to failure by virtue of the fact that the GPL is irrevocable (clearly spelled out in the license; if you license code to me under the GPL, you can't change your mind later. It's mine to use, modify, and distribute under the GPL in perpetuity, so long as I remain compliant with the GPL. And of course, anyone who receives it from me also has that right to use and redistribute it), it is also quite likely to make his software relatively unpopular. If he takes it proprietary and anyone actually uses it for anything, someone will created a Free fork (and probably already has), which will become the standard version of the software, while his is relegated to a relative niche market, like proprietary SSH.

So everyone who downloads software to provide them with more security from http://openbsd.org/ or http://www.openssh.com/ or http://www.gnupg.org/ is an idiot?

screen rtorrent

ssh youraddress

screen -r -x

The only new thing here is the standard format for the compliance with the court order (and the new requirement that you be able to produce the records for the court). Most ISPs have been saying, "yeah, we don't have that information because we wouldn't have the capacity to store it, duh" up until now.

Did you feel like your civil liberties were stripped away when the court authorized a wiretip on so-and-so or whats-his-face? How do you suppose the court or the legislature would react if your telco said, "Yeah, we don't have the equipment to tap that line." I don't think that would go over so well. Thus: CALEA.

What frightens me a great deal more than the ability of the court to order us to produce data (and the requirement that we store it) is the remote control wire tapping device installed at the police station that can listen in on any line at our small phone company.

They're supposed to get a warrant first, but my feelings indicate that if I were a cop (and believed I was helping people) I probably wouldn't bother with a warrant until I knew there was something to get a warrant about. That is much more serious than this. Let me introduce you to my little friends openssl, openssh, openvpn and gnupg.

If you believe the discrete log problem is "hard" then you have no worries. Now try doing that with your phone...

What's wrong with Fedora Core 1? Why not use that version still and just keep patching it? Why not use the very first version of OpenSSH + patches? Why not use a commercial, proprietary, non-open source, non-free ssh implementation?

Why not just use telnet and to hell with the ongoing development of OpenSSH and upcoming innovative ideas... ;-)

Let's face it, RedHat is just like MS to take and make money, not to give back unless it's for publicity to make even more money - that's why they have Fedora Core, let the laborers work for them for free... and the rest if obvious...

http://openssh.com/users.html

Just my $0.02

The basic idea behind privilege separation is that OpenSSH sshd(8) has something like 27000 lines of code. A lot of them run as root. However, when UsePrivilegeSeparation is enabled, the daemon splits into two parts. A part containing about 2500 lines of code remains as root, and the rest of the code is shoved into a chroot-jail without any privileges.

Once this work was completed, the scope for root exploits (as measured in LOC) was reduced by 90% for all time. Alternately, one can view the new landscape as permitting a factor of ten increase in the resources available to conduct security audits on the 2500 lines of code which retained privilege. Perhaps if the key talent hadn't been so busy implementing priv sep, they might have had the resources available to discover the root exploit before it tarnished their unblemished record. Note that this exploit was not present in the 2500 line kernel that retained privilege.

Furthermore, the actual code defect (in the prospective non-privileged code base) was not discovered by some zit-faced l33t or random black-hat.

e. We believed very strongly that the issue was unknown in the

Maybe they would migrate to Linux but why would you want then, They are computer-backward folks who have not updated their equipment. They will be a support nightmare.

Additionally why do you want to encourage them to use legacy hardware? It uses up more electricity to get the job done than modern hardware. Makes the user less productive. Why encourage that.

Ssh yourself. You're the one giving them ideas ;)

Later licenses restricted the use of ssh in a commercial environment, instead requiring companies to buy an expensive version from Datafellows.

I have to wonder how long it will be before the commercial SSH folks are talking to apple and sun and so on about really cheap bulk licenses.

1. Slackware Linux. Still the best after all this time.
2. OpenBSD. Just because you are paranoid does not mean they are not out there trying to get you.
3. OpenSSH. Because you just can't use plain text telnet anymore.
4. Rsync. Just because.
5. GNU Screen. Triple your terminal productivity. Now with minty-fresh taste!
6. GNU Wget. Because you have better thing to do than watch over a download.
7. Vim.Because Emacs is for losers.
8. Nmap. Look at 'OpenBSD' above.
9. IPTables. Lock that machine down, admin boy.
10. pf. I said, lock that machine down , admin boy!

Another statistic suggests that more than 80% of the SSH servers on the Internet run OpenSSH. I'm wondering if you have ever verified which version they are running, and what is the average behaviour of an OpenSSH administrator. Does people update the server as soon as a new release is available?

Damien Miller: Funny you mention this, we just completed another version survey with the assistance of Mark Uemura from OpenBSD Support Japan. The results of this should be going up on OpenSSH.com soon.

I don't have detailed OpenSSH version histories for usage surveys before last year's. Certainly the use of paleolithic versions (such as 2.x) is very infrequent, but beyond this it is difficult to tell how quickly users update - many vendors will keep relatively ancient versions (such as 3.1p1) on life-support with spot security fixes. This will avoid known security problems, but it doesn't give their users the benefit of any of the proactive work that we do, nor any of the new features.

It is worth noting that OpenBSD, which has a very conservative policy on its stable trees, typically updates supported OpenBSD releases to the latest OpenSSH version when it is released.

Being very popular means also being a good platform for a worm. Did you adopt any specific measures to fight automated attacks?

Damien Miller: Privilege separation alone probably makes a worm targeting a bug in sshd impractical. An attacker would need to break into the unprivileged sshd process that deals with network communications and, because this just gives them access to an unprivileged and chrooted account, then exploit a second vulnerability to either break the privileged monitor sshd or escalate privilege via a kernel bug. This would add a fair amount of complexity, fragility and size to a worm - it would probably need to implement a fair chunk of the SSH protocol just to propagate.

We also implemented self re-execution at the c2k4 Hackathon. This changes sshd so that instead of forking to accept a new connection, it executes a separate sshd process to handle it. This ensures that any run-time randomizations are reapplied to each new connection, including ProPolice/SSP stack canary values, shared library randomizations, malloc randomizations, stack gap randomizations, etc.

Without re-exec, all sshd child processes would share the same randomizations. This would allow an attacker to exhaustively search for the right offsets and values for their exploit by making many connections (millions probably) to the server. With re-exec, each time they connect the values will all be different so there is no guarantee that they will ever stumble upon the right combination.

Another security improvement, just introduced in openssh-4.2 was the "zlib@openssh.com" compression method. This was an idea that Markus Friedl had after the last zlib vulnerability was published.

The SSH protocol has supported zlib compression for a long time, but the standard "zlib" protocol method requires this to be started early in the protocol: after key exchange, but (critically) before user authentication successfully completed. This exposes the compression code to unauthenticated users.

Our solution is to define a new compression method that still performs zlib compression, but delays its start until after user authentication has finished, so only authenticated users get to see it. This is another significant reduction in attack surface with effectively zero performance impact. This also makes the writing of a worm that targets the zlib code in OpenSSH impossible.

Did you develop any measure to fight timing based attacks?

Damien Miller: There are two classes of timing attacks, one of which matters and the other is not so important.

The not so important timing attacks allow active detection of which usernames are valid by differing timings i

The commercial variant is actually the original. That company was started by the guy who first invented the ssh protocol in 1995. The source was open, but apparently newer versions were released under successively more restrictive licenses. openssh was forked from one of the earlier versions and then modified for v2 compatibility and other fixes. You can read about the history of the protocol here and here. The first link is from O'Reilly and starts at the beginning with Tatu, and the second is written by the openssh developers, but curiously says very little about ssh before they forked it.

While I support anyone's attempt to operate a legal business, the statements by Rashed are mostly FUD and just sound like a company with lackluster sales trying to drum up business. Pathetic.

If you have different goals, start your own project.

If you're unable to spend the time to know how to properly submit a patch then it's your problem, not theirs, it's their project.

If you are wanting something to be accepted into it, you have to make it work the way the developers want it to work.

Your attitude is completely asshat backwards, it's not up to them to help you get what you want, it's up to you to get them what you want. But if you want to add in support for an algorithm that is patened, too bad, it won't happen. If you want to start favouring PAM, too bad. If you want to have it support the GnuTLS, too bad.

How hard is it to conform to the KNF? Are you saying it's so hard to conform to good coding guidelines that it's not worth adding the functionality you want? Fine, the functionality won't be added.

This isn't forcing their personal view on anyone, it's enforcing their views on their own project. No one is forcing you to be a user, there is no knife held to your neck waiting for the second you download lsh.

Don't like it? Go cry to your mother, maybe she can make it all better.

That's not true. "cathedral-style" may be a somewhat loaded term, but it does refer to a clear, well-defined difference of the underlying model of a piece of software - the development model, in most cases, but it can also be applied to others. Call it "top-down" if you want to, or contrast it with terms like "grassroots" etc.

"enterprise-scale", on the other hand, isn't - rather, that's an ephemeral quality that your own products always possess, but never those of your competitors.

I think the real point here is that SSH Communications are trying to sell a product, so it's only natural that they're trying to show their competitors in the worst possible light, especially when those competitors have around 90% market share (see http://openssh.com/usage/graphs.html). OpenSSH, on the other hand, is not trying to sell you anything - like most open-source projects, their primary concern is to produce the best possible software. If you use it, good; if not, it's your loss, not theirs.

Theo and OpenSSH have a problem, brute force attacks. When asked about it he doesn't want to do the extra work to make OpenSSH more secure. Yea, it's a multi threading problem and he says just go use some other software that will mask his problem by putting up a firewall rule in front of his OpenSSH code.

Then try talking to him about passphrases. This guy is a danger to everyone's security. OpenSSH should be replaced or forked as soon as possible (open source only please).

Try asking him, watch what you get back.

http://www.openssh.com/list.html

Could be wrong here but...

I am looking at the portable OpenSSH 4.2 source tree right now.

http://www.openssh.com/

Scanning the openssh-4.2p1 directory, what do I see?

aclocal.m4
configure
configure.ac
etc.

That looks like an Autoconf-based build system to me.

Poster didn't even link to the supposedly "better way to do it".

So why is this modded interesting?

For OpenSSH, the ssh2d_config(5) man page:

AuthInteractiveFailureTimeout

Specifies the delay, in seconds, that the server delays after a failed attempt to log in using keyboard-interactive and password authentication. The default is 2.

A decelerating response might be customized using plug-ins if AuthKbdInt.Plugin were configured.

If I were you then I would contact Theo to see how you can get the box to a developer. By the way, no matter who you end up donating it to, it's an awesome gesture on your part. Good on ya.

TFA is insufficient and history can be found here: http://www.openssh.com/history.html/.

That marked the OpenSSH 1.2.2 release, which was shipped with OpenBSD 2.6 in December 1, 1999.

Further...

With the OpenBSD 2.6 release out of the way, Markus Friedl decided to pursue SSH 2 protocol support. Slaving away for months, he managed to keep OpenSSH slim and lean, while at the same time managing to turn it into a single piece of software that could do both the SSH 1 and SSH 2 protocols. This version, called OpenSSH 2.0, shipped with OpenBSD 2.7 on June 15, 2000.

That would make it over five years old, much older if you count the groundwork laid with OSSH, and 2.0 is coming up on its fifth birthday.

I use ports of it with public key authentication on Windows and Linux. I salute the people who've worked so hard on making and keeping this going. OpenSSH is at the top of my "must have working or it's a no-go" list of tools for remote access and security.

AFAIK, it's not OpenBSD people who do the porting to Linux. Which explains the bugs you get in OpenSSH on Linux, and not on OpenBSD: One team does strictly OpenBSD-based development, aiming to produce code that is as clean, simple, and secure as possible. We believe that simplicity without the portability "goop" allows for better code quality control and easier review. The other team then takes the clean version and makes it portable, by adding the portability "goop" so that it will run on many operating systems (these are known as the p releases, and named like "OpenSSH 4.1p1")(from: OpenSSH

Sure most have one or two innovative features, but what applications in the OS world are really innovative, especially from an end user perspective?

Certainly not desktop environments, servers, remote shells, anonymizing (or swarming) networks, or compilers.

Because all of those things are just replacements for commercial applications, and did nothing new.

#6a) If you really must, must log in remotely (as root or anyone else, you must always use SSH - no exceptions! Always assume you're network is being sniffed. See (2) above.

FWIW I verified that the uploaded files are in fact correct.

Way to be 733t, dude.

First, my universal advice: DON'T get in the habit of fixing remote systems for free. It is a huge time-sink & it would be better if you don't foster that dependence. I sometimes fix problems over email or in person for friends/family, but I also usually weasel some free beer out of the deal.

That being said, many have to remotely administer machines for OTHER reasons. Oftentimes, a shell is all that is needed & having OpenSSH is good enough. It is available for win32 too. This can also be used for port forwarding if other daemons are needed.

If you don't need SSH/SFTP & do need a secure connection, setup a VPN. OpenVPN is great:cross-platform, secure, and easy to install. IPSec is still the standard, but I don't bother with it unless I have to (like when my company would buy a hardware implementation). I try to avoid PPTP. It works OK on windows. Not so well on other platforms (poptop does a pretty fair job, though). It also believe it has some known (but, I again believe, still unexploited) security weaknesses.

You hooked on the GUI? I use VNC over VPN or stunnel. I don't really like remote desktop, but if you have to support it put RDesktop on your *nix box. FreeNX is, in many ways, better than both. I like it a lot, but I haven't used it under windows (it can be done & someone might have made it quick-and-easy, but I try to avoid supporting windows machines).