OpenSSH Project Now at openssh.com

Anonymous Coward writes "The OpenSSH project now has a central webpage at www.openssh.com. OpenSSH is based on the last free version of Tatu Ylonen's SSH with all patent-encumbered algorithms removed, all known security bugs fixed, new features reintroduced and many other clean-ups."

Comments

Good to see the publicity...

[pb]

Nice page, too. Think they use blowfish, much? :)

I, personally, could care less, but I'd love to see that this stuff can be included in Debian and all the other purist distributions, and contributed to, and stuff. That's the good part.

Besides, the licensing for SSH 2 got worse, I understand, and that's why we have free versions: to protect us from that.
---
pb Reply rather than vaguely moderate me.

Improved security

[bjk4]

One aspect of OpenSSH that many people should like is that the most recent security hole in ssh-1.2.27 was non-existant in OpenSSH. For that reason alone, OpenSSH might be a better choice -- especially with the lack of developer news concerning ssh1 and ssh2.

-B

ps. Check www.securityfocus.com for the bugtraq archives and mailing list.

Good to avoid dumb US laws

[Anonymous Coward]

Excellent, now we have an open ssh package. No more visiting RedHat's ssh page and filling out those "are you a US citizen" forms before I can securely login to a remote machine.

Seriously, why does the US even bother with cryptographic export laws when many other countries can ship products that contain the same strength encryption as they are trying to keep locked up?

Especially with open source projects involving encryption that are being developed all over the world, this country's policies seem downright pointless.

Or am I missing the point?

Re:Good to avoid dumb US laws

[Wanker]

Actually, OpenSSH and the original ssh are equally affected by US laws against exporting cryptography. The difference is that the OpenBSD people are not located in the US, so they don't need to worry about exporting ssh. If RedHat weren't a US company you could already download ssh RPMs from them without filling out any forms.

Of course, you can already find RPMs for ssh from other non-US sites. Try rpmfind.net.

Re:Good to avoid dumb US laws

[Forward The Light Br]

DISCLAIMER: I do not support this law, I just want to explain it.

Seriously, why does the US even bother with cryptographic export laws when many other countries can ship products that contain the same
strength encryption as they are trying to keep locked up?

the theory goes, that much of the crypto (and generally, much of the research in areas restricted by this law) reseach in this country is sponsored at least partly by the federal government, the development of crypto entirely in the private sector is a new developement (as opposed to simply implementing it, which has been private sector for a while)

The federal government did not want to fund research that could come back to haunt them in terms of inhibiting SIGINT obtained overseas from being useable.

Realize that this is an old law, and the crypto battle between the Soviets and the US was very active for much of the last 50 years.

Even now, the US government has an interest in trying to prevent strong crypto from existing outside this country, and in point of fact, most currently existing crypto DOES originate from inside US borders (SSH included)

the only caveat is that the US Judicial branch has ruled that the federal government had better have a very compelling reason to inhibit written speach. To legislate prior restraint is almost impossible...

to keep the law constitutional, written algorithms were exempted from the law.

That is how PGP got outside the US, and how OpenSSH was able to exist.

Even if some crypto is leaking out, the USG has a compelling interest in trying to read foreign SIGINT.

I think they should just invest more money in finding ways to break the codes, as that is likely to be more effective, but I fault them more for their methods than their motives...

-RS
We are all in the gutter, but some of us are looking at the stars --Oscar Wilde

Re:Good to avoid dumb US laws

[Roundeye]

Even now, the US government has an interest in trying to prevent strong crypto from existing outside this country, and in point of fact, most currently existing crypto DOES originate from inside US borders (SSH included)

Hmm? Tatu Ylönen is a Finnish programmer and SSH Communications Security Ltd is a Finnish company.

Now, take this one step further...

This would imply that US export restrictions have the most effect upon US citizens and corporations. Since the rest of the world merely goes to an archive (in say Finland) and doesn't bother going to the US for crypto, US citizens, being used to getting nearly everything from American sites, go to American sites and have to fill out forms and sign agreements and do a two-step to download crypto components.

Net result -- the US government knows who has crypto, and also puts barriers in the way of those trying to get crypto (every additional click and form submission reduces the % of Americans likely to download crypto). Why would they care???

Because they're concerned with spying upon the American people -- and crypto slows that down.

Drop the export restrictions and there's no good excuse to make Americans fill out forms to get crypto.

Starting to make sense?

[ by the way, mr. 3-letter agency, I use PGP, GPG, SSH, SSH2, OpenSSH (now), IPsec/IKE/ photurisd/isakmpd, PGPNet, anonymizer.com, the new beta of Freedom (zeroknowledge.com), DES, 3DES, blowfish, StegFS, outguess, twofish, Kerberos, and I'm sure some others that I've forgotten. I'm a US citizen. Screw you criminal bastards. ]

Re:Good to avoid dumb US laws

[Forward The Light Br]

I was under the impression that SSH had originally been developed inside the US, (perhaps by Mr Ylonen) and then when time came to incorporate, they moved overseas...

then again, maybe I am full of shit ;-)
We are all in the gutter, but some of us are looking at the stars --Oscar Wilde

I must speak up.

[Anonymous Coward]

Debian has been coerced into renaming the OpenSSH package to SSH. In other words, people who are upgrading their system will have the real SSH transparently removed and replaced with OpenSSH.

There is no warning although the functionalities are not equivalent. The original SSH package has been renamed.

It is my understanding that all this has happened at the bequest of Theo. This is yet another case where POLITICS interferes with the TECHNICAL aspects of Debian.

Re:I must speak up.

[phred]

"Coerced" is awfully strong language. So is "politics." Some might even consider them swear-words. Instead, may I suggest: "Consistency." "Principles."

As is often the case, here we have someone wanting to make a noisy controversy out of a normal event. The background, as I understand it, is that the OpenBSD folks didn't much care for the Data Fellows licensing policy for the new ssh, so they decided to rewrite the old version 1 as OpenSSH, and in the process nipped at least one known bug. The new version will be in OpenBSD 2.6 scheduled for release on December 1.

Meanwhile Debian decided to substitute this version, in line with its policy to have only totally free packages in the free distribution. The other version will continue to be available in non-free.

It's not as if this is some deep dark secret, nor has it been some big folderol. Matter-of-fact coverage can be found at BugTraq, OpenBSD and the Debian development lists.

There was also an announcement in Joey Hess' Debian Weekly News last week -- and here is the real scoop from Phil Hands.

"Politics" myass.

-------

Re:I must speak up.

[Tom Christiansen]

People have no sense of humor these days (Russ excepted :-).

it's important to support this

[SEAL]

I will try to avoid the classic open / closed source arguments here, although they creep in a little bit :-)

I think OpenSSH is very important to everyone. License status aside, it represents an alternative way to use the SSH protocol. Some people may prefer it while others may like the closed source version. But I think more people overall will be using one of the two. This is a good thing. There's still alot of plaintext authentication on the net, and I'd be happy to see less of it. POP3, FTP, and telnet are all commonly used, for example.

We all know the average user is lazy about passwords. Sniffing one password often compromises many things. Yes, the user is at fault but now the sysadmin can do something about it (namely wrapping the protocol in SSH). With OpenSSH, perhaps more sysadmins will agree with the licensing.

Additionally, I seem to remember reading somewhere that the IETF needs two independent implementations of a protocol before it can progress towards being an official standard. (Someone correct me if I'm wrong - I'm sorry I don't have a link to provide). With that in mind, SSH can get the IETF's blessing before a corporation with its own goals decides to muck with what should be in the standard.

Just my $.02

SEAL

Re:it's important to support this

[arcade]

We all know the average user is lazy about passwords. Sniffing one password often compromises many things. Yes, the user is at fault but now the sysadmin can do something about it (namely wrapping the protocol in SSH). With OpenSSH, perhaps more sysadmins will agree with the licensing.

For me and you, and probably the rest of the slashdot readers, its obvious that sending passwords in the clear is a Bad Thing (tm). The problem is that most people don't give a damn about getting their passwords sniffed. (Ha! Someone may read my email! What a catastrophy!). I've heard the last argument at least 10 times during this term at the university ALONE.

What they don't realise, is that they compromize a LOT more than just their email. They make the systems vulnerable to local exploits. Careless users is a *Bad Thing* -- but they don't seem to care.

Why don't sysadmins just disable telnet / ssh and so on? Well, the problem - of course - is that would send people rioting. People want to use the application they're used to. They don't give a damn about security. Me, and a lot of other administrators, tend to set up pop3only accounts - so that if the pop3 pwd is compromised -- nothing but the persons email is available for the sniffer (i hope? :-). But, if they use the same pwd for their pop3 and for their shellaccount - then there is trouble.


You mention the lisence. Yes - a lot of us want to be 'good buds' who use the open source things. But, if it means that I've got to compile Yet Another Program - then it will be done .. tomorrow. Always tomorrow, never today. That means it will take time. People will start using it - SLOWLY. Not necessarily because they are afraid of using something new -- but they want to do LESS work. And, since they're already using the non-GPL'en version , and using it happily -- why should they do a lot of "unneccessary" work? (I will do it.. in time.. because I want to support the Effort. ;-)


ohwell, yet another long slashdot rant in my probably far to shabby english.


--

Re:it's important to support this

[Forward The Light Br]

This is a good thing.
There's still alot of plaintext authentication on the net, and I'd be happy to see less of it. POP3, FTP, and telnet are all commonly used, for
example.

Join the IETF working-group mailing lists for these protocols! Most working groups (at least the one I am on) while not requiring an actual consensus, try for general agreement before making a decision, so if you have a good idea for a protocol, join up and let everyone know about it. You will be surprised what the ratio of corporate-sponsored members to random folk are on these WGs (heavily in the commercial folk favor) try to even it a bit. ;-)

Additionally, I seem to remember reading somewhere that the IETF needs two independent implementations of a protocol before it can progress
towards being an official standard.

I am pretty sure this is correct, I remember seeing it on the (commercial) ssh webpage of all places ;-)

-RS
We are all in the gutter, but some of us are looking at the stars --Oscar Wilde

Re:How does this effect Psst?

[NovaX]

But this is more than free speech, this is liberty.

Re:Can it be used OUTSIDE of the USA?

[NovaX]

That's the point. You couldn't distribute SSH in america to foriegners. OpenBSD is based in Canada (so it gets passed all the mess US laws), so yes.

I think, but I likely have this confused, that US developers couldn't design a free implement because of the patents and export laws. When OpenSSH came out, I remember one of my LUGs chatting about wanting to port or copy (whichever got Linux the most credit), but were annoyed because US developers would only hurt the project.

Re:Client for 'doze?

[demon]

I recommend Tera Term Pro and the TTSSH extension if you must use Windows. Or use MindTerm, which is a Java-based SSH client. I've used both, and they both work well with any SSH 1.x server. (Including OpenSSH.)

OpenSSH

[fries]

re psst .. I'm sure any contributions from psst
would be welcomed, and I'm sure psst can read the
license and note they're welcomed to any code in
the OpenSSH tree, but a merger I doubt would occur, considering the different audiences each
is addressing.

re sshv2 protocol, it is a freely available spec,
and as such, has potential to be implemented in
OpenSSH (although has not yet been done). The
initial thrust of OpenSSH was to have something
equivalant to and compatible with ssh-1.2.x in OpenBSD 2.6, and that has certainly been accomplished. It is certianly not illegal to implement it in a free product; that the commercal
'ssh2' program costs something is the company
charging for their programmers, not the protocol.

While the incident with 1.2.27's security bug doesn't necessarily suggest OpenSSH is more secure in general, it does seem interesting to note that
in the code cleanup of creating OpenSSH, the bug
was accidentally fixed. Hats off to the programmers who have a high enough standard of coding that they accidentally fix bugs :-)

ClosedSSH has superior algorithms? I implore you to back your statement with facts. Last I checked, the algorithms available in OpenSSH are
limited to those in the crypto library, and there
may be less algorithms in OpenSSH than ClosedSSH
because of this, but why include the insecure ones?

Beware of two things. First, I'm not a lawyer. Second, I believe my understanding of the crypto laws suggests if you compile it outside the us, you can use it outside the us, if you compile it inside the us you can't ship it outside the us,
and if you use it in the us, you can't use an
alternative to rsa's library if you wish to use
that particular algorithm, which at this time
requires commercial entities to talk to rsa for
licenses. I think. Someone maybe should confirm this though.

Read the man page for logging in from a particular ip without a password. Look for .shosts.

Re:OpenSSH

[tweek]

Read the man page for logging in from a particular ip without a password. Look for .shosts.

Or search google for RSAAuthentication. You should come across a .gov mailing list that discusses a bit about it. There were too many URL's to list here. The only reason I even mention it, is that I spent 2 hours last night trying to get it to work for this webcam software that I'm trying to get to replace ftp with sftp and didn't feel like putting the recompiling the damn thing everytime I changed the password on that account.
"We hope you find fun and laughter in the new millenium" - Top half of fastfood gamepiece

Re:Client for 'doze?

[CloudWarrior]

Putty's another good client, although its not particularly configurable at the moment.
CloudWarrior . "I may be in the gutter but I'm looking to the stars"

Why OpenSSH

[Wanker]

There seems to be a bit of confusion about exactly what this software offers over the standard SSH. Hopefully I can help clear it up a bit.

• Licensing

  SSH1 comes with a license which is rather ambiguous about commercial use. The most common interpretation is that it's OK to use it commercially so long as one isn't making a profit directly off it. (e.g. charging people for the software.) SSH2 is much clearer-- in order to use SSH2 in a business you must use the closed-source, $400-a-server version from DataFellows.

  Here is the vague portion of the SSH1 license:

  Companies are permitted to use this program as long as it is not used for revenue-generating purposes. For example, an Internet service provider is allowed to install this program on their systems and permit clients to use SSH to connect; however, actively distributing SSH to clients for the purpose of providing added value requires separate licensing.

• Compatibility

  SSH2 clients cannot talk to SSH1 servers. This was by design in an attempt to drive people to upgrade to the new protocol. SSH1 clients are able to talk to SSH2 servers.

• Patents

  The IDEA (default) algorithm is patented and requires a license to use commercially. The RSA algorithm is also patented, but that patent has either expired or is about to expire. If one can find a copy of "rsaref", formerly offered freely from RSA's FTP site, then one can use it instead of the internal RSA algorithm to work around this little hurdle.

One reason there is demand for another implementation of the SSH protocol is so that people in small businesses can continue to use SSH while still maintaining access to the source code and also staying $400/server closer to being profitable.

Given the incompatibility of the clients, upgrading from SSH1 to SSH2 requires a flag day upon which day every client and server must be simultaneously upgraded to SSH2. Trying to upgrade in stages results in those with SSH2 unable to connect to SSH1 servers. It is possible to install both versions of the client, but the user will have to be the one "failing over" to the other version. Irritating at best, costly and time-consuming at worst.

For more information about SSH implementations, check out the Open Directory Project's SSH Category.

Re:Why OpenSSH

[Forward The Light Br]

Compatibility

SSH2 clients cannot talk to SSH1 servers. This was by design in an attempt to drive people to upgrade to the new protocol. SSH1
clients are able to talk to SSH2 servers.

I must disagree, if one compiles ssh1 and then ssh2, ssh2 autodetects its existence, and compiles both the ssh2 daemon and client such that it can accept connections from ssh1 clients, and connect to ssh1 servers.

ssh1 clients cannot connect to ssh2 servers w/o this, as the protocols are completely non-interoperable.

FWIW, the SSH2 protocol is actually better

Given the incompatibility of the clients, upgrading from SSH1 to SSH2 requires a flag day upon which day every client and server must be
simultaneously upgraded to SSH2. Trying to upgrade in stages results in those with SSH2 unable to connect to SSH1 servers.

again this is incorrect, a "proper" installation of ssh2 over ssh1 will not have this problem unless you specifically compile ssh2 to not have compatibility (which would truely be foolish)

-RS
We are all in the gutter, but some of us are looking at the stars --Oscar Wilde

Re:Why OpenSSH

[Wanker]

Unfortunately, it is not easy to do a "proper" installation on a Win32 system. (Which, curiously enough, are the source of most of the complaints about SSH1 servers.) The DataFellows SSH2 Win32 client simply refuses to connect to an SSH1 server. I'll admit that it has been many months since I tried, so it's possible that they've since come to their senses.

Don't even get me started about wishing for a better scp client. (The only one I know of requires CygWin-- which is too large for many users to download.)

A great many people install just ssh2, assuming that since it's newer it will connect properly to all existing ssh servers. These people usually get a nasty surprise and start complaining that the ssh servers are "broken". I'm forced to agree. ("Broken as designed" comes to mind...)

It's also a toss-up whether a binary distribution was built "properly" or not. Of course, something as critical as ssh really ought to be built from the sources, but laziness can be a great motivator.

BTW, I agree that the SSH2 version is a better protocol-- I just wish DataFellows had implemented it so that the upgrade could be more trouble-free.

Re:Why OpenSSH

[Forward The Light Br]

no, if you install ssh1 and then ssh2 on a server, ssh1 clients will be able to connect to the server transparently, on *BSD or Linux or any other *nix...

_however_ if one does a pure SSH2 install, the ssh1 client cannot connect... all I meant was that the protocols are mutually incompatible...


We are all in the gutter, but some of us are looking at the stars --Oscar Wilde

Caveat

[Forward The Light Br]

I have to admit I have issues with the OpenBSD folks who are maintaining OpenSSH.

Their code is very BSD oriented, makes no attempt to be portable. (this is not inherently a huge sin, I am sure it was tiring writing the thing in the first place ;-) ) So some guy in Australia ports it to Linux/autoconf-automake so it will compile on Linux and other *nixs...

Along the way, he introduces PAM (which is a *nix standard, OpenBSD just chooses not to use it) and in general improves the code (I don't have the rest of the feature list handy)

instead of allowing him to merge it back into the code tree, or even offering to host it, www.openssh.com takes credit for it by adding a link labeled "Linux/Solaris" and links directly to the ftp location. No acknowledgements, no link to the web page.

This sort of snottiness may or may not be endemic to the *BSD community, such a generalization would be unfair. HOWEVER it _does_ worsen their reputation, not to mention fly in the face of the commonly accepted code of ethics that accompany the open source concept.

I do not mean this as a flame of anyone other than those from the OpenSSH project who were actually involved in the decision to ignore the compatibility initiative. The rest have my unequivocal admiration and gratitude, as the product itself (OpenSSH) is very impressive, and we all should thank them for volunteering their time to provide us with it.

And for the record, other than admiring him and his work, I have no relation to that chap from Australia nor his port of OpenSSH to Linux...

-RS
We are all in the gutter, but some of us are looking at the stars --Oscar Wilde

Re:Caveat

[fries]

Interesting concept. Did you even bother to
suggest that the web page be changed before you started openly flaming a volunteer effort here?

Here's a thought for you. Most of your networking package, daemons, standard rpc and telnet and ftp and etc came originally from ... bsd!

So do you condone the BSD world for not supporting
Linux in their source trees? What on earth would ever entice them to do so?

If you consider it 'not nice' to provide a link to an existing usage of the OpenSSH program, what do you expect to happen from your statements? I daresay that any contribution to the source will be credited in the commit message, the typical way of giving credit in any BSD project. If no contribution from that Linux port was given back, why should you be complaining?

As for the suggestion that pam is a unix standard, well, as far as I'm concerned it is typical of 'blind and free' software advocates views. Have you ever looked at the pam sourcecode? It is a mess. A hideous mess. On top of that it is hard to figure out and even harder to implement a new module. And you TRUST this convoluted mess as your authentication standard? Any clues as to why BSD has chosen to use the 'true' unix standard POSIX libc functions as their 'standard' authentication library?

Since OpenBSD is the only distribution I know of that has the ability to ship with a package in the core os that is encrypted like it is, why the problem with the fact that you have to download and do your own custom patch each time you want to update the OpenSSH you have? BSD has been doing this for years with a system called 'ports'. 'make install' in the proper directory, and files download themselves, patches apply themselves, source builds itself, and without further interaction the package has been upgraded. It's not a new concept is my point, and I don't understand how you can suggest it is worse than trivial to accomplish.

If OpenSSH hosts any packages, and they refused your particular author's package, that would be one thing. But do you see a 'list of downloadable packages' on the web site? I don't. I see a reference to where the source is and the first os that is going to ship with the software, as well as a reference to every other os that has implemented packages of the software. How in this planet can that be anything but fair?

If anyone wishes to contribute and improve the OpenSSH that is freely available, without tainting its freely available license, I cannot imagine it would be unwelcomed. This implies implicit activity on the behalf of the contributor, not on the OpenSSH development team whos jobs are not defined as 'go digging through all packages created from OpenSSH to detect any potentials for contribution' ..

As for the complaint about being BSD oriented, well, apparently that is not something that cannot
be overcome, it works fine in Linux as many fine individuals will attest, and it may even suggest more secure ways of programming (mkstemp anyone?).

Lastly, I suggest you get yourself an attitude check. You do the free community a dis-service by dissing some very hard working developers who have provided you with a freely available product. Guess what freel avilable means? If you don't like it, you have the source. It does not mean if you don't like it you have a right to complain until things go your way. You could always grab
yourself a copy of OpenBSD, pay secnet.net for
support, and whine at them waving your money till you are satisfied, but I doubt your money is where your mouth is.

Re:Caveat

[elflord]

nstead of allowing him to merge it back into the code tree, or even offering to host it, www.openssh.com takes credit for it by adding a link labeled "Linux/Solaris"

Wait a minute ...

• The OpenBSD crowd are a small team, and they've been working their butts off on OpenSSH. They can't integrate the fixes into the source tree overnight ( remember, they will need/want to audit every line of code ).
• Do they really "take the credit" ? If all contributor's names are in the credits file, then they are playing fair. If not, you may have a point. ( It looks like they do give credit - see this thread )

I don't think the OpenBSD people are being exclusivists. And I think you should be a little patient. I think they will cooperate. However, the OpenBSD place emphasis on quality development, not "rapid development". Don't expect everything to happen overnight.

Re:Caveat

[dmiller]

As the "guy in Australia" who made the changes you mentioned, I cannot agree with your view. The OpenBSD developers have been very accomodating and we have been actively swapping patches and bug reports. I have not been "improving the code" as it is of good (and improving) quality already.

I have no expectation that the OpenBSD developers choke their CVS tree up with cross-platform cruft. Part of the reason why their OS is so clean and secure is that there is none of that junk in there. As mentioned previously, we do exchange patches to close bugs and add features.

Finally I find it ironic that, in a diatribe about how others failed to give me due credit, you didn't even bother to use my real name.

Anonymous Coward submits Crypto Story?

[MagicMike]

I have to say, with all the privacy stuff getting posted on /., and the entire "Your Rights Online" section, maybe its about time we recognized that being anonymous is actually a pretty brave thing.

When I look back on it, I used to think being "anonymous coward" was cowardly, nowadays I'm thinking its not going to be too long before there's no choice in the matter...

To be on topic for a bit, I just installed OpenBSD (yes, after I read the /. thing, okay, I'm a lemming), and its really very very nice. OpenSSH is from the same crew, and they do very good work. Tight security. Astounding documentation. Attention to detail. Very nice. More power to them.

Perhaps you should have kept quiet...

[Phil Hands]

no warning:

The package tells you exactly what is going on using the shiny new debconf tool to put a nice dialog box up to ask you if you want to continue, or give you the chance to install ssh-nonfree instead.

Coerced:

As the Debian maintainer of both ssh (OpenSSH) and ssh-nonfree (the non-free ssh) I can tell you that the decision was mine. (I did check that nobody from the OpenSSH team minded)

My decision was based on the fact that Debian does not consider non-free software to be part of the distribution, so if there is a free and a non-free implementation of a package, the free one gets the name because its actually part of the distribution.

I've got nothing against ssh-nonfree (otherwise I wouldn't have maintained a Debian package of it for years) and I really appreciate the fact that Tatu wrote it, and allowed us all to use it. It just happens to be non-free, so the DFSG free alternative gets priority in our case.

I hope that clears things up.

Cheers, Phil.

Re:Perhaps you should have kept quiet...

[Phil Hands]

Then what is the point??

You had an unfounded objection to something. I explained why it was unfounded. What more point do you require?

You are still clobbering the original program with another completely different one.

Given that the two programs in question are branches of the same source tree, and that OpenSSH is intended to be a drop in replacement for ssh-nonfree, characterising them as completely different is ridiculous.

This is madness and I'm sorry you don't get it.

LOL

You are without point

[Phil Hands]

Debian never distributed the SSH package anyway.

If debian never distributed ssh (which comes as a surprise to me, given that I've been maintaining it for over two years) then why are you complaining that it overwrites the old package?

Why does Debian decide to BREAK the user's system by RENAMING packages?

If OpenSSH has broken your system, please report a bug, and I will endeavor to resolve your problem.

If on the other hand you are just being an idiot, please shut up and stop wasting our time.

Cheers, Phil.

I should've explained better

[SEAL]

Sorry I guess I wasn't very clear, especially with my little slip up about licensing.

First part: stupid users

The idea here is to make things transparent to them. Let them use their same old apps, but make the behind-the-scenes networking secure. For example, some mail programs can now connect using SSL. If a sysadmin sets it up this way, the end user doesn't usually care (or even know). That's how we need to attack the stupid-user problem. I agree with you that we can't rely on them to get un-stupid.

Part 2: licensing

I said that having OpenSSH in addition to SSH will serve to increase the number of people using this protocol. Reason: I was thinking of the sysadmin ohhhh... like ME :) who wanted SSH installed at work, but was prevented from doing so because the boss didn't want to pay for it. OpenSSH is a blessing for people in my position.

Other companies may prefer to purchase SSH so that they have someone to call up when things go wrong. That's OK too - there's nothing wrong with paying for a commercial version. I think it is a good thing to have BOTH implementations out there.

Best regards,

SEAL

Yes, you are missing the point.

[jcr]

The jackbooted thugs aren't interested in keeping anyone dangerous from having encryption, because that's a hell of a lot of work. The purpose in all this petty harassment of coders and publishers is to prevent strong cryptography from becoming common and more importantly, turn on by default.

Right now, nearly everything is in the clear, and that makes work much easier for FBI agents on fishing expeditions without a warrant.

Make no mistake, crypto restriction serves *no* legitimate law enforcement purpose. It's only usefulness is to enable illegal acts by governments agains law abiding citizens.

Check into the use of PGP by Amnesty International, and look up what kinds of slimy tricks J. Edgar Hoover pulled on Martin Luther King and others.

-jcr

Re:LSH, another alternative

[K�gedal]

Lsh is not really ready for real-world use yet, but it's making progress. It's based on the IETF spec on the SSH2 protocol.

For developers who want to have a look at what's being done, you can have a look http://www.lysator.liu.se/~nisse/lsh/.

SSH v1 / v2 clients

[Outland Traveller]

I use Vandyke's SecureCRT software, which is a win32 SSH v1, v2, telnet, and general terminal emulation client. Version 3.0 lets you connect to either SSHv1 or SSHv2 servers with lots of encryption/compression/port forwarding options. If you're using a client like this a v1 to v2 server upgrade "flag" day isn't as annoying as it could be.

I don't have any affiliation with Vandyke, but I would like to say that they make beta releases readily available, return email promptly with a personal reply, and emailed me the the upgrade license from version 2 to version 3 without any "upgrade" charge. Yes, it's closed, non-free software, but much better than most I've dealt with.

-OT

SSH does NOT originate in U.S.

[Eric Green]

It's a European product, remember?

I think the AES competition (www.nist.gov/aes), a competition for the replacement of DES by the U.S. government, should finally put a end to the lie that the U.S. has some kind of monopoly on encryption. A full 40% of the finalists were foreign in origin, despite a selection process that was biased for American solutions.

Similarly, while MIT/RSADI hold the U.S. patent on the RSA public key encryption method used in SSH, most modern cryptographers believe that RSA public key encrpytion is obsolete. Most of the work on its proposed replacement, elliptic curve cryptography, is being done in Britain and Canada (in fact, the biggest vendor of elliptic curve cryptography is Canadian).

Don't get me wrong, the U.S. still has many great cryptographers. Bruce Schneier, Ron Rivest, the list goes on. But I seriously doubt that the U.S. still does the majority of public cryptographic research. If you don't believe me, go browse the cryptographic links section on my home page.

-E

good god, will you please knock it off?

[vyesue]

if you dont like debian, dont use it. this is why we have fourteen thousand linux distributions. I'm quite certain you can track one down that doesnt get your panties all in a knot.

if the maintainer of a distribution wants to change the distribution, and if users of the distribution are allowed to use other distributions, there is no problem at all. I see no way to compare this to "OH WHAT IF MICROSOFT DID THIS".

quit bitching. thanks!

Re:Question for those in the know.

[Eric Green]

Most Linux compiles of 'ssh' have for years defaulted to the Blowfish encryption method rather than the patented IDEA encryption method that was removed from OpenSSH. If you wish to connect to a 'ssh1' server from an OpenSSH client, it will automatically adjust to use BlowFish. If you wish to connect from a 'ssh1' client that was not compiled to default to Blowfish, you MAY need to pass it an option to tell it to go to 'Blowfish' rather than IDEA.

One thing I'd like to do is remove the RSA encryption entirely from SSH and replace it with a non-patent-encumbered method of doing the public key authentication. RSA really isn't necessary anymore, there are now patent-unencumbered methods for doing public key session key exchanges and public key digest authentication without use of the RSA patented algorithm. My understanding is that RSA was kept in OpenSSH because it's necessary in order to maintain backward compatibility.

So yes, backward compatibility should be maintained by OpenSSH, unless something seriously stupid was done. I'm about to go test that theory personally :-).

-E