OpenSSH 3.5 Released

Dan writes "Markus Friedl announces that OpenSSH 3.5 has just been released with notable updates since 3.4. It will be available from the mirrors listed at http://www.openssh.com/ shortly. Enhancements include bug fixes, improved support for Privilege Separation (Portability, Kerberos, PermitRootLogin handling), RSA blinding in order to avoid timing attacks against the RSA host key and much more. Congratulations are in order for the OpenSSH team's hard work and efforts."

Comments

sweet

[Anonymous Coward]

so when will apple roll it into os x?

Re:sweet

[Anonymous Coward]

why wait for apple? just compile it yourself....thats the beauty...

OpenSSH 3.5 --

[Anonymous Coward]

now with 3.5 times MORE security holes!

Re:OpenSSH 3.5 --

[thefalconer]

So, is this a recommended download, or a "required lest you get hacked" type download? Also, when's the posting time for the updates, I haven't seen any sign of it in the ports tree yet.

Re:OpenSSH 3.5 --

[Anonymous Coward]

yeah you should stick to telnet maybe,? openssh has had some spectacular problems lately, but it
has a much better record than almost anything
else. And the security benefits it offers make
it irreplaceable. What will you do use pptp,
secure remote, telnet, cisco vpn client, crazily
broken ms ipsec client,.. the list of the much
more imperfect methods for securely accessing
computers is very long.

Check those MD5s!

[egg troll]

Remember to check the MD5s of those downloads this time around!

Re:Check those MD5s!

[MrWa]

I know this is a good idea, but if someone were to put a trojan in the OpenSSH code...how much harder would it be to put an MD5 that matches the modified code?

Re:Check those MD5s!

[malfunct]

I am talking with very little knowledge here, but wouldn't you need to have the private key that OpenSSH used to generate their MD5? Or am I completely wrong and MD5 doesn't use public/private keys?

Re:Check those MD5s!

[Anonymous Coward]

Because hax0red the FTP server and replaced the good binaries on the FTP server with hax0red binaries. The MD5s (which youcan verify from several places) are of the good binaries. So, the simple answer is don't trust the MD5 from the FTP server.

Re:Check those MD5s!

[Chuuk Noris]

MD5 doesn't use public/private keys. It actually doesn't use any keys at all. It just produces a short checkum (a short string such as "aa44cfb..."), that you can compare with another checksum later, in order to tell if anything has changed.

That said, it can still be useful-- for example if you get the MD5 checksums from the "main distribution site" or whatever, and then download the actual files from a mirror. That said, a (PGP|GPG) signature is still better.

Re:Check those MD5s!

[archen]

easy, you check the md5 of the md5.

Re:Check those MD5s!

[Caled]

If you don't have a copy of md5, you can download it here.
;)

Re:Check those MD5s!

[drthornt]

Presumably the authentic author has their own md5 hash for the pacakge that they posted to news groups the moment after it was generated. Now even if the the Authenic author own bocen is haX0red he/she can in 128 bits flat figure out that it's been tampered with. I think that the best we can expect from the situation where the Publishing site has been HaX0red is that the authentic author can detect it in a resonable amount of time.

Re:Check those MD5s!

[Anonymous Coward]

PGP/GPG and MD5 (or MD4 or sum(1) or SHA1) are 2 entirely different beats, though.

PGP is for cryptography. MD5 verifies a copy of a file is the same as the original. If Damien is bored and decides to insert a trojan, it doesn't help you any if you know with 100% certainty that it was him.

carefull...Quote from site

[L0gAn]

....trojan was discovered in the OpenSSH ftp distribution on August 1st. Anyone who upgraded between July 30 and then is encouraged to read the following advisory to learn how their system may have been compromised.

At least one major security vulnerability exists in many deployed OpenSSH versions (2.3.1 to 3.3). Please see the ISS advisory, or our own OpenSSH advisory on this topic where simple patches are provided for the pre-authentication problem.

Re:carefull...Quote from site

[crimsun]

Thanks.

The MD5 checksums for the official and portable tarballs are provided in the announcement here.

Debian

[qortra]

I'm a dedicated Debian user; does anyone know the usual lag in getting a new version of OpenSSH into the mirrors (I'm guessing it would go into testing or unstable)?

Re:Debian

[dcstimm]

Yeah debian isnt mainstream anymore, programs have to be stable to get into debian "unstable".... How smart are they?

Re:Debian

[mindstrm]

Unless it is a security fix, I believe it will go into unstable.

Re:Debian

[crimsun]

There's a fair amount of testing that takes place before the packages are updated. I wouldn't count on 3.5pX going into Sid for a while yet. The more critical fixes might be backported against 1:3.4p1-4, etc.

Wait a while...

[carlmenezes]

Wait a while to see if any errors/security holes pop-up. THEN go out and download it. Chances are you've already patched the version you have. Don't replace it with the new one until you're sure that's a good thing. It'll just save you a lot of extra work.

Re:Wait a while...

[Anonymous Coward]

The CVS tree is public - bad guys have just as much of a shot a finding holes in unreleased code as they do the released versions

Re:Wait a while...

[mick129]

...but not as much motivation when the unreleased version is not installed on many machines.

Re:Wait a while...

[zeekiorage]

With warnings like this, nobody will upgrade and no errors/security holes will come out ;).

I think if you check the MD5/PGP signatures you should be fine.

Re:Wait a while...

[Anonymous Coward]

checking the md5sums will prevent any security holes from being found in the code? amazing, maybe microsoft should md5 their updates and then people using their software will be fine and safe from holes.

Re:Wait a while...

[Spit_Fire1]

NT admins have had this philosophy for years, although most people trust Microsoft less and with good reason.

Re:Wait a while...

[evilviper]

That is the most ridiculous philosophy...

The S/Key exploit wasn't discovered until about 4 releases later. If a piece of software is exploitable, there's no magic formula that will result in you getting it after all the bugs have been fixed.

It makes some sense for Windows, since everything is secret until a release, and is thrown upon the world in an instant, getting spread far and wide to different enwironments. So, bugs are found, but still doesn't help in the security department.

Re:Wait a while...

[Anonymous Coward]

With warnings like this, nobody will upgrade and no errors/security holes will come out ;).
checking the md5sums will prevent any security holes from being found in the code? amazing, maybe microsoft should md5 their updates and then people using their software will be fine and safe from holes.

No, he/she/it means that everyone will be too scared to upgrade, the new version will not be used, and so there will be no new exploits.

Use your imagination, you AC!

Re:Wait a while...

[dmiller]

Chances are that this release has fewer security problems, rather than more. If it does have security problems, they are highly likely to affect older version as well - the amount of completely new code is not that great.

Slow Down

[Anonymous Coward]

If you do not have concerns with running the latest 3.4, do yourself a favor and let the 3.5 release wait for a few days. OpenSSH has actually become one of those apps I worry about now, joining the ranks of Sendmail and BIND. What a shame...when software designed solely for the purpose of increasing security cannot be trusted, what is left? Trust nothing I suppose.

Re:Slow Down

[Anonymous Coward]

when software designed solely for the purpose of increasing security cannot be trusted, what is left?

Not standard telnet. That much is for sure.

Re:Slow Down

[erik umenhofer]

It's not the software that having the security problem, it was a hacked server serving up the software and people not checking thier checksums. Don't blame the software when you didn't check your sum.

Re:Slow Down

[Anonymous Coward]

I beg to differ. Read the Security Notices and weep. I further contend that source of the compromise has nothing to do with the end result. As such, OpenSSH is officially on my "be wary of list" and will remain there. If not for the actual problems in OpenSSH itself, then simply because it is such a high value target.

Re:Slow Down

[pope nihil]

I'd like to point out that the security record of OpenSSH is much better than sendmail or bind. Having a bug like this only once in a while is better than average.

Re:Slow Down

[Anonymous Coward]

... OpenSSH is much better than sendmail or bind

Hell, you might as well include Microsoft Outlook in there because that ain't sayin much.

Re:Slow Down

[evilviper]

Because Privlidge Seperation is in there, even a serious bug will (now) only result in a compromise of a non-privlidged user account.

That's enough to negate any concerns.

Re:Slow Down

[Anonymous Coward]

This isn't true; there were a number of versions of ssh with remote compromises before 3.4.

On the other hand, its track record is still better than both sendmail and bind. And what else are you going to use? Telnet? VNC? Terminal Server? They all have worse problems.

Re:Slow Down

[oh]

Because Privlidge Seperation is in there, even a serious bug will (now) only result in a compromise of a non-privlidged user account.

That's enough to negate any concerns.

I've heard this argument before, and I don't think it holds water.

Firstly, do you patch all local privilege escalation vulnerabilities as quickly as you patch remote vulnerabilities? I know I don't.

Even if there are no local vulnerabilities, they can still scan you system for useful information. They can then use you system to attack other systems from behind you firewall. Do you have a local firewall rule that disallows all outbound connections?

We had a presentation from a (proxy) firewall vendor that used a hardened OS. They were very proud that each proxy ran in its own little sand-box. The mail outside mail daemon could only access port 25 on the outside NIC, and could only pass email to the inside daemon via a shared spool directory. Their OS prevented any other access from that process.

Whenever we asked about a specific version of a daemon, they would refer to this sand-boxing and tell us that it wouldn't matter if a particular proxy was hacked out, there was no way the hacker could break through the firewall.

The company I worked for ran one of the largest (top 10, maybe top 5) web sites in our country. There would have been maybe a dozen other websites with similar bandwidth, and maybe the same number of ISPs. We had to sit down an carefully explain to these sales people that even if the hacked proxy could only access one port on the outside NIC of the firewall, it could DOS almost any other site in the country.

They left that presentation with worried looks on their faces, and promised to get back to us with the version numbers we were asking for.

Moral of the story: Any malicious use of you systems is a bad thing. "Privilege Separation" may stop them from rooting the box running OpenSSH, but a malicious hacker could still do a lot of damage.

Re:Slow Down

[Anonymous Coward]

it could DOS almost any other site in the country.

Nothing personal, but I don't care about the security of your box, especially when compared to the security of my box :)

That said, if whoever designed the product didn't consider the other security vulnerabilites of it, then it doesn't say much about the product overall.

Re:Slow Down

[dmiller]

Firstly, do you patch all local privilege escalation vulnerabilities as quickly as you patch remote vulnerabilities? I know I don't.

Please RTFM: An attacker breaking privsep will find themselves in an empty chroot jail with a unique, non-priviliged UID & GID. Leveraging such an attack to even read local files would be very difficult.

Your points about a broken privsep being used to stage network-based attacks are valid.

Re:Slow Down

[EvilAlien]

The moment you start trusting without question is the moment you should give up paying attention to security. Trust is a vulnerability.

Re:Slow Down

[oh]

but I don't care about the security of your box, especially when compared to the security of my box

Care. If you are in the US you are even more vulnrable to this then those of us in countires with a smaller internet presence.

The site I worked for had enough bandwidth avaibale to take a noticable chunk out of the countries international links. If some one couldn't hack your site, but could hack a large site "close" to you then they could DOS you out of existance. They much not be able to hack you, but they can shut you down. For a home site, maybe you don't care? If you running a business off the web, its bad news.

Re:Slow Down

[evilviper]

Your points about a broken privsep being used to stage network-based attacks are valid.

Don't agree with this point exactly... For one thing, many firewalls (I know PF does) have user/group based filtering... So you could block all outbound traffic from the sshd user. Besides that, a chroot can be created that gives the service NO space on the filesystem, meaning they can't even download an DOS tool if you haven't used the afore mentioned firewalling method. I personally use quota rules to make sure some services don't have the ability to write anywhere, even if they aren't chrooted.

Re:Slow Down

[evilviper]

Umm, I should also have mentioned... Even if you take NO measures to secure your chroot, since it is not a root account, using it for DoSing wouldn't be (nearly as) useful, since you can not spoof the IP addresses. At that point, it is more useful to break in to Windows machines for the same purpose.

Besides, what would you use instead? SSH.com's insecure version, which is known to be vulnerable, and doesn't provide priv. sep. at all?

Re:Slow Down

[Bert64]

Also, once soimeone has broken into the sandbox.. they still obviously have access to the daemon they exploited... so they could shut it down, have it serve false content, or log authentication attempts.

Re:Slow Down

[Bert64]

A simple ddos tool could even be integrated into the shellcode of the exploit, it wouldn`t be impossible.

Re:Slow Down

[dmiller]

That assumes the presence of outbound filter rules. (Your idea to filter the privsep user is an excellent one.)

You wouldn't need filesystem space to launch an attack - you can upload code into the compomised process' address space, though getting this right would be tricky.

Re:Slow Down

[evilviper]

That assumes the presence of outbound filter rules.

What does? Spoofing? The privsep user is not root, and therefore does not have the proper permissions needed to stick forged packet directly on the wire.

You wouldn't need filesystem space to launch an attack - you can upload code into the compomised process' address space, though getting this right would be tricky.

Not only would it be tricky... It wouldn't allow for long-term situations-it will only be there until the machine is rebooted. That only gives the attacker a very small ammount of space to work with, and can be limited even further with login.conf / ulimit rules, giving the user access to only a very small portion of memory, swap, stack, etc.

embedded ports for OpenSSH

[gperry]

Has anyone worked on an embedded port of OpenSSH, specifically the AMD / Alchemy au1500 MIPS core or ARM9?

Re:embedded ports for OpenSSH

[Anonymous Coward]

yeah, it's called the openssh portable release. to make it run on my arm9 sidewinder (linux), i had to do the following:

untar it
type ./configure
make
make install

(remember, the order of the commands is important)

My one bugbear

[muzzmac]

Have they put in provisions to separate the SFTP and interactive shell or command execution protocols?

Last time I tried to play with SFTP I could not get an external company to have SFTP access without a lot of shell level mucking around to stop them having access to log in via shells or rlogin style features.

And yes I'm lazy, yes I should ask the question in the correct forum and yes I should probably contribute to the project but I am, I couldn't be bothered finding it again and I would be useless to them.

Anyway congratulations and thinkyou for what is other than my stupid whinge a great product. (Opensource or otherwise)

Re:My one bugbear

[Big Jason]

You might want to check out scponly.

Be aware of the colour scheme on that site though, it's hard on the eyes.

Re:My one bugbear

[Anonymous Coward]

Don't kid yourself.

scponly is a mess.

It sporadically works with some clients, and not with others. Granted some of this is the clients fault, but not handling these different (but ultimately identical) access methods (ie getting listings at different times, etc) make scponly a one-tricky pony.

Re:My one bugbear

[Phibz]

I've used the scp-wrapper perl script and it works excellently. I add a dsa key for the client and in the key in authorized_keys i add command="/usr/sbin/scp-wrapper" ......

Basically what the script does is clean the environment. The requested command is stored in SSH_ORIGINAL_COMMAND environmental variable. Its checked to make sure it is in fact the command you intend. The options are then checked. Finally the script exec()'s the hardcoded path to the command with arguments supplied.

Although it comes written for scp i've used it for securing an account so they can't log in, and they can only execute one or two commands of my choosing.

from what i understand sftp just exec's /usr/libexec/sftp-server. i don't see why you couldn't alter the script to only allow that command.

also you'll want to make sure the client's ~/.bash_profile, ~/.profile, etc.--all its login scripts--are empty and owned by root so that they don't upload their own "special" login script and undo all your work.

scp-wrapper can be found here

Phibz

Re:My one bugbear

[Big Jason]

Use the source Luke.

Stop yer whining and fix the fscking problem, unless you have a better solution.

Re:My one bugbear

[Anonymous Coward]

check out RSSH at http://www.pizzashack.org/rssh/. From that page: rssh is a restricted shell for use with OpenSSH, allowing only scp and/or sftp. For example, if you have a server which you only want to allow users to copy files off of via scp, without providing shell access, you can use rssh to do that.

Re:Everyone should use OpenSSH

[Anonymous Coward]

Don't mod this assclown up

Hah, this is kinda funny...

[coupland]

That Linux trojan/virus writers have learned to aim at Linux sysadmins by taking control of very recent patches and adding trojan horses. Seems the best way to attack a Linux system is to try to interrupt the many vigilant admins as they faithfully download patches on the same day they're released... Windows trojans survive on the dearth of upgrades, not their spread...

Re:Hah, this is kinda funny...

[Anonymous Coward]

Yeah, but I still get Code Red nibbles, so I'm not sure you can argue they "survive"...

Stupid question..

[distributed.karma]

What does this have to do with BSD, as opposed to other Unixen?

Re:Stupid question..

[erik umenhofer]

OpenSSH is part of the OpenBSD project. BSD being the key word.

Re:Stupid question..

[Kwikymart]

The same people that make OpenBSD make OpenSSH?

Whenever some story about, say KDE, pops up everyone is like "this is the best thing for Linux since sliced bread". Reality check: not all people run KDE run it on Linux. I think the BSD people should be entitled to the same "This is what we do for everyone!" type of recognition as everyone else.

Re:Stupid question..

[Clover_Kicker]

>What does this have to do with BSD, as opposed to
>other Unixen?

OpenSSH was written by folks who also work on OpenBSD.

Of course, OpenSSH runs on many different *nix flavours.

Re:Stupid question..

[Anonymous Coward]

yu0 == teh ignorent!!

Re:Stupid question..

[Anonymous Coward]

OpenSSH was ported to Linux??? Since when!?!?!?!? I've been using it in OpenBSD for the longest time. Guess I lost track of my desktop OS (er, kernel) Linux boxes...

Re:Stupid question..

[Clover_Kicker]

>OpenSSH was ported to Linux??? Since when!?!?!?!?

Very soon after the initial release for OpenBSD.

There's a brief history of the project on the OpenSSH web site.

But, but....

[Anonymous Coward]

They told me BSD was dead!!!

Re:Everyone should use OpenSSH

[Anonymous Coward]

Don't mod this assclown up

MD5 is just a hash...

[Goonie]

It's not (in itself) cryptographically signed.

You could either GPG sign the MD5 hash of the tarball, or GPG sign the tarball itself to guarantee that the tarball was signed off by the appropriate person.

Re:MD5 is just a hash...

[wirelessbuzzers]

They do have a GPG detached sig. The portable version is signed by Damien Miller (and verified, and it matches the MD5), for example. But, on the other hand, Damien miller's key has no sigs on it, so there's no reason for us to believe that it really belongs to him...

So, in the end, you're just going to have to trust that *somebody* isn't out to get you, unless you want to run through the source code line-by-line... ...Or, you can download it now, wait a few days (faster than examining the source), and see if they post "OpenSSL trojaned!!" to the front page of Slashdot, then install it. Take your pick.

Re:MD5 is just a hash...

[jovlinger]

heh.

I'm smiling because that was the method of security that M$ use(s/d?) for activeX controls. Widely derided as unworkable, and prone to misuse (IIRC, someone got hold of a M$ private key, and they had to revoke it.)

le plus ca change...

Re:MD5 is just a hash...

[kasperd]

Damien miller's key has no sigs on it, so there's no reason for us to believe that it really belongs to him...

Even before this trojan history I was pedantic about avoiding a trojaned version. I downloaded Damiens public key from every mirror and verified they were identical. I have kept this key around since then, so if anybody were to create a fake key for Damien, I would notice.

Re:MD5 is just a hash...

[dmiller]

But, on the other hand, Damien miller's key has no sigs on it, so there's no reason for us to believe that it really belongs to him..

The key has been pretty widely distributed and has been used to sign OpenSSH releases since nearly day 1 (I used a pgp2.6 key for some of the earlier releases IIRC).

If the key were to suddenly change, it would be noticed (note that this is exactly the trust model that sshd host keys use).

I would like to get some signatures on the key, but haven't had much opportunity. Hopefully I'll get off my behind and go to the next Asia-Pacific IETF conference and get some sigs there.

Where is the public key to check the sig?

[Anonymous Coward]

I can't seem to find a link to openssh.com's public key. I'd like tp putz about with this new version tonight, but I'm not putting it on any server until I can get its contents verified...

So... any ideas where it might be found?

Re:Where is the public key to check the sig?

[wirelessbuzzers]

If you are referring to Damien Miller's public key, you can get it off the keyservers. Or, you can get it right here:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGP 8.0 (Build 288) Beta

mQGiBDqa5pwRBADJSEyXXsgXiyytN93prDPTPmrueRP9lQQf ga QvCvqK0bN0AF1Z
Vxxk9wlSXQp3+Qw5+qqsN5ovzsn39r9pqG slfCqQn9ACTmsn42 +VCyW4hdwUGSBS
5myh65ZJTK1ufWCZFssxQ0EiALagu4DlH6 Z2O7tFDnJNagF55v lnK0uMQwCg/8RU
QYDmisEHjkarAapPaupxjhkD/j9riCVasW PYJwAuhiQWAKxGRw p/ZyTaWCSERUBR
4Dg9QxpuwHKIT8BeDA3hJa/9Yxu5jec2NV KbtVSZvRkgUfRNOk rcH2eiY8Iz6est
J64dGWuGMKQW0GEqW+OXpRTTPJZ0mgPmU1 6qDzLPdx6F3BAk2L G+TTwlKUPuGqOt
6u2EA/4+1CBYZ8mXq9GJnLRBPAoYwSJJzb QnMm9Jat/yg9N6ni gSIiFyG8ixh167
gGGKfzvpjY7DeJzDI0Cub+tRova8gFg+T1 5AcPMST5v7v6O/ug 9aYWERZ0zjUhRH
ybtYLYhUUbdYM29PwGBNfZhGIOYwfFE9Up PS5LeXHs28oVLlH7 QuRGFtaWVuIE1p
bGxlciAoUGVyc29uYWwgS2V5KSA8ZGptQG 1pbmRyb3Qub3JnPo hXBBMRAgAXBQI6
muacBQsHCgMEAxUDAgMWAgECF4AACgkQzo 7LA4b/nEiDMgCZAU zKq241h5GTJxC0
guS6ht9i9ZsAoL/oXCmFsofARehZF6AakI dasvS9uQINBDqa5t QQCADz/XnCcyle
9hmxgyntr35ZQJKx9g6ftBw178JSwM3O7J NOGp398Eh4Q9rkEp 5NH1qVecG953Fu
edT9IAXqr8pjp5tdqMYCcaKy+aJ0Sw1zVD 2VOY3h7SyfU25pcY iHEa1grfKPVoWm
53IwWGVVtquF5dimAe75+D0aXyVCOv0Ez9 wgJR6H69lp4/cD2G yNaGarwY9HLvHF
vXONY2qm/GV5OjyOUO41gmQ4pyXQh+gocF FHrM0AzveIswgNpJ 0xNWXX8iXGsr3Y
Cvqm7JoIU9JKxDV+96bxDLfTdKpoLYKb68 WdtmAylsio5+iZfW tdOb/Xpk2Yx5Ld
ady9/+n3m6cvAAURCACrvoVSbd0MR0FWX+ bBZ0NjScNBo3kPSS CnQ6jRHokkz55r
+MHe7dqxCJ3pmu7aROl2fgug6wob+7+qXf Kke/TdT6wuCb4CdF S6tPgPrfYV+iwq
2NB/BatePGg7Z6UALaULQ0m83DCEVLJNnj emEdIouShelikAAO 7QDKMr7vAjH8n0
zwMpwRMXnvCM6zYlS9i1kOm8LVATk0Wyih pQGSaTukdPjKlG7s KwMu20ssK9DGVp
PgulTZ7rHqXl4juY8LQ2j4dPNaPoKWG8Ju BVCsyf2D6GNW97Pf KQSkzFeZsbVB4S
RQrVTchgBSYoxRVW3fLk/yc3TC5Abh6Gpj 4izawUiEYEGBECAA YFAjqa5tQACgkQ
zo7LA4b/nEgftgCdHIZUDVAWDRa5siSi8A os+IiyAgAAn02wGO l1Wo/YJ+RY+c6K
N58TmAPE
=rCFY
-----END PGP PUBLIC KEY BLOCK-----

Re:Where is the public key to check the sig?

[rweir]

If I'm paranoid enough to verify the signature, do you really think I'll be using the key someone posted on Slashdot?

Re:Where is the public key to check the sig?

[mmca]

I agree. Look for djm@mindrot.org on your favorite keyserver. (I like the one below)

http://pgp.mit.edu:11371/pks/lookup?op=get&searc h= 0x86FF9C48

M

No holes this time.. just minor fixes and upgrades

[StupidKatz]

There are numerous "fixes" which strengthen openssh in general, but there's no security hole mentioned. Looks like this is just something to do during the next weekend! That is, after everyone ELSE puts it on their production servers, heh heh.

Why I Switched to OpenSSH

[Anonymous Coward]

OpenSSH gives me the flexibilty and versatility that I demand in mobile computing. As a professional freelance writer, I rely on OpenSSH to customize itself to the way I work to get my job done.

Before I was using F-Secure SSH, and I always had problems with technical things my poor brain can't comprehend. Now I just tar zxvf openssh.tgz; ./configure; make; sudo make install and generate my public and private keys. It's so easy! OpenSSH gives me more power for less dough -- Girl Scout's honor!

OpenSSH. It's about more and better.

Re:RSA

[Anonymous Coward]

True. But what's the exact run-time complexity of that encoding schema.

Re:RSA

[mindstrm]

Doesn't work.

Are you misshg some chars there?

Wish list item

[Froze]

One stumbling block to major acceptance of ssh outside the admin community is the ability to resume downloads. I wish they would add this.

Re:Wish list item

[twistedcubic]

Maybe you could try rsync -e ssh. I've never tried it, but maybe it would just download the diff, which would just be the remainder of the file in this case. Just a random thought, which may not work :)

Re:Wish list item

[joe_bruin]

your wish is granted. say you got the first half of pr0n.tar.bz2:

$ ssh remotehost -c "tail --bytes=\`ls -l | awk '/pr0n.tar.bz2/ { print $5; }' - `ls -l | awk '/pr0n.tar.bz2/ { print $5; }'` | bc\`" > pr0n.tar.bz2

now, you're smart enough to turn this into a shell script, right? there's a reason openbsd doesn't ship with a "watch" script.

note that there is probably an error in that commandline since i never tested it. go ahead, post it.

Re:Wish list item

[joe_bruin]

nevermind, your answer is far better than mine.

but does it look as cool?

Re:Wish list item

[Anonymous Coward]

I haven't tested that command line either, but I'm guessing that now you've got the problem of only having the _second_ half of the file.

Re:Wish list item

[piyo]

Nope there's an error.

I tried narrowing it to just the first term where it is getting the remote file's size:

$ ssh remotehost "ls -l | awk '/pr0n.tar.bz2/ {print $5};' "

but it returns the whole line:

-rw-r--r-- 1 user user 10121951 Oct 16 21:40 pr0n.tar.bz2

Apparently gawk-3.1.0 doesn't work the way one expects when one uses it remotely. Maybe you want to try again, because I'm stumped.

Re:Wish list item

[joe_bruin]

good point. make that > a >>

Re:Let's just hope...

[drthornt]

I hope they do find them tommorrow, my client's will be asking me why I haven't deployed this and I want some ammunition.

Re:No holes this time.. just minor fixes and upgra

[drthornt]

IMHO , ain't broke don't fix it. If it's broke, test test test some more then test the upgrade (and back-out) process, then roll it out. Wee!!! change control.

Well then...

[Goonie]

Mr Miller should get his key more widely signed then.

No solution is perfect, but some additional peace of mind could be provided with not a lot of extra effort.

Re:Well then...

[wirelessbuzzers]

Mr. Miller should get his key more widely signed then.

Signed by whom? It would take a people signing each other's keys for him to get into my (relatively small) web of trust. And if he isn't, there is absolutely no reason to trust the sigs. If someone wanted to impersonate Damien Miller, they could just make 10 fake keys and sign Damien's fake key with them. So you just have to trust that this is the right key, in which case you might as well take it on faith that the file isn't trojaned or that the MD5 sum is correct.

I'm not that paranoid, so I don't care. The MD5 matches, as does the sig, which convinces me. I also have a Mac, and Apple hasn't released a native installer for this yet, so I might as well wait and save myself a messy UNIX install (have to dowload a bunch of libs otherwise), in which time any forgery will be discovered anyway.

Note that a quick search indicates that there are no less than 5 currently active and 3 inactive keys belonging to "Damien Miller" (and there seem to be about 5 different Damien Millers who use PGP) on the keyserver, so there's not much reason to trust that this one is actually him.

Mike

Re:Well then...

[Anonymous Coward]

Signed by whom?

Well, every version of PGP comes with Phil Zimmerman's key, so he's pretty much the "certificate authority" of the PGP world. It would be quickly noticed if one distributed a fake Zimmerman key.

The other answer is VeriSign and something like Authenticode.

Sigh

[starseeker]

I see some highly moderated comments that are saying that ssh is no longer to be trusted, and what's left now?

My contention is that there NEVER WAS any software as secure as these people seem to have though ssh was, and there never will be. It's just too complex a game, and there are people who seem to live on nothing but attacking systems. Given that combination, there will be weaknesses found, as long as humans are a part of the development equation.

The situation has been improperly defined by the assumptions we've apparently made. Don't expect UNCRACKABLE software - that's just silly. What we have seen with openssh/openssl is exactly what we should be seeing - inevitable problems being openly discussed and fixed quickly. What if someone were to put a trojaned MS update onto one of Microsoft's servers? Would we even know for months? This kind of crap happens. It's part of the cost and reality of using computers.

Take the rash of reports of vulnerability as a GOOD thing - it's better to know and fix, than wait for a black hat to find it. Of course we try to code and design to avoid weeknesses, but the reality is that life doesn't work like that, and we need to be ready to handle the problems that crop up. Whether or not this is an indication of a design flaw in ssh doesn't really matter either - that can also be fixed. That's what ongoing development is all about.

So don't diss SSH too much. Constructive discussion only, please. Remember, it's free, it helps, and it's only getting better. If you don't think it's good enough, help them! You can, you know - open source at it's best.

Re:Sigh

[PigleT]

"Don't expect UNCRACKABLE software - that's just silly."

Agreed. Note also the move towards running fewer services and firewalling so that only ports 22 and 80 are open - and wide open, at that. It is my guess that we wouldn't see so many PHP scripting vulnerabilities on bugtraq if people wrote native applications instead of web-apps for e.g. calendaring, groupware, etc, but using their own custom port#s for the purpose instead of flattening everything onto 80.
I'm not surprised that sort of thing has brought forth a rash of ssh updates.

I'd also like an alternative to openssl and openssh, other than freessh and lsh which aren't all that well developed yet, but time will tell on that front.

Re:RSA

[Permission Denied]

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",
)]}\EsMsK sN0[lN*1lK[d2%Sa2/d0

NO CARRIER

You again. Excellent troll, but you need to choose a different motif for your nicks.

For the uninitiated: that is not perl. It is line noise with some perl operators, bundled into a cleverly-masked troll. This guy is an old sport at this, previously using the name "PhysicsGenius". Check his (short) user history, and this guy's posting history. I simply cannot believe that moderators would be so idiotic as to mod this stuff up, so my conjecture is that he has two accounts: one to troll, and another serious account with mod points. It may be interesting to correlate average time between mod points to his posting history.

Relevant anecdote: the original OpenSSH sources had an "RSA in six lines of perl" in a comment of one of the source files. Theo removed that in some version. A little too much angst there, if you ask me - this stuff is supposed to be fun.

Re:Still like the commercial version of ssh better

[Anonymous Coward]

I'll be trusting a Anonymous Coward astroturfing for a commercial product which has had far more security holes than the free alternative... NOT

Re:RSA

[Anonymous Coward]

Theo? Fun?

Too much change?

[timeOday]

Today at work I got a phonecall. The admins portscanned the network, found out I was running OpenSSH, and made me remove it and install a precompiled F-Secure SSH. This bugs me because who knows what they might have implemented my new precompiled ssh?

Anyways, I think they scanned for OpenSSH because of the recent problems. It seems they release a new version every couple of weeks. There are bound to be bugs. Now, I tend to think that closed-source software probably has more latent bugs and there's just no way to know, but the perception is that constant change means instability and insecurity.

Re:Too much change?

[PigleT]

Your sysadmins are obviously pillocks if they either (a) believe everything in a version banner or (b) don't understand that it's better to have a fixed bug than a multitude of unknown bugs.
Time to update the CV...

Re:Too much change?

[Anonymous Coward]

figure out what the f-secure version banner is a patch openssh to have that banner.

Re:Too much change?

[comcn]

Seems fairly easy to avoid: patch OpenSSH to return a header that identifies itself as F-Secure SSH instead. Probably a one-liner.

Re:Too much change?

[gol64738]

it's likely that the sysadmins had you replace your open source products with a commercial one for blame/fault purposes.
big corporation sysadmins like to point fingers when something fucks up..otherwise, it's their head.
by sticking to commercial software, corporate sysadmins can keep that shitball rolling, all the way back to the product company.

Re:Too much change?

[Bert64]

But commercial software authors also give you "ABSOLOUTELY NO WARRANTEE"
I really dont expect a warrantee from something i get for free, but if i pay for something i would like it to work, and i would like comeback against the provider of the product if problems with it cause me trouble.
Example, a few weeks ago a garage fitted a new fanbelt to my car, but it was the wrong type.. it was somewhat too small, it bent the alternator mountings and quite quickly snapped. With no alternator, the battery quickly got discharged as i was finding a safe place to stop, and i was unable to restart the engine.
The garage replaced towed me for free, replaced the alternator and the belt, and gave me a courtesy car while the work was carried out.. I didn`t try to push it and ask for financial compensation, since i wasnt going anywhere especially important at the time..

10.2.x?

[Anonymous Coward]

While it's possible they'll roll it in to 10.2.2, which is due in a few weeks, I find it unlikely. 10.2.3 would seem to be the earliest time reasonable if OpenSSH 3.5 turns out fine; but it's possible that Apple won't move at all from 3.4 unless there's a security flaw in 3.5, as feature wise, there doesn't seem to be a major incentive to upgrade like there was 3.1 to 3.4.

Any security fixes?

[roly]

I'm running OpenSSH 3.4p1, any security fixes in 3.5p1?

compatible keys

[snatchitup]

I would like to see a version that create key files that are compatible with putty and securenetterm. Right now, if I want to use SecNetTerm, I've got to create the key on the Linux box with ssh-keygen, copy it to my pc, load it into putty to convert it, save it out, then move it over to SecNetTerm. Not only that, I couldn't find an easy HowTo that told me how to do this. It took several hours to figure this out.

I shouldn't have to be a guru just to use SSH.

Re:compatible keys

[Bert64]

The keys generated by openssh are afaik, compatible with the original ssh. most likely these other programs you mention use their own format for keys, in which case you cant blame openssh.. afterall, how are they supposed to support every nonstandard third party keyfile format?

Re:compatible keys

[snatchitup]

That's true. But consider that what www.OpenSS.org lists on its website at the top of it's page for alternative operating systems Windows & Mac.

The following "free" clients are recommended for interoperating with OpenSSH from Windows machines:

* PuTTY is an SSH1+SSH2 implementation. PSCP, an scp-style program for Windows, is also available.

PuTTY is available under the MIT licence (BSD-like).

"PuTTY is a free implementation of Telnet and SSH for Win32 platforms, written and maintained primarily by Simon Tatham, who lives in Great Britain."



If you're going to recommend it, then why not right up front, give some pointers on how to get it up and running.

Regards.... S

Re:compatible keys

[Bert64]

It`s less of a recommendation, and more of a "this is the only free client that doesnt require you to install tons of libs"

GPG Verification

[Kozz]

I swear to God I'm not a newbie... I've been working with linux for a few years, and still learn something new every day. I tried to be a good boy and verify the gpg signature, but I couldn't figure out how to do it. Got a link for a how-to? Google doesn't turn up much of anything useful at openssh.com or gnupg.org.

I've got GPG installed, a private/public keypair created for myself, now what?

Re:GPG Verification

[Anonymous Coward]

gpg ---verify /path/to/detatched/sig /path/to/thing/to/verify

you probably also want to uncomment keyserver-options auto-key-retrieve from your ~/.gnupg/gpg.conf and uncomment one of the keyserver lines

So-called proactively secure...

[Bert64]

I`m sure i will be modded down for daring to flame the openbsd team, but anyway..
For an os and other tools (openssl, openssh) which is supposedly thoroughly security audited, there have been a lot of vulnerabilities found, some even present in NEW code (as opposed to the original code that openssh for instance was based upon)
It sure says a lot about the auditing skills of these people if blackhats have been able to find and exploit so many holes, which their supposed auditing missed.

Re:So-called proactively secure...

[Anonymous Coward]

The problem with your argument basically has to do with the tense of your verbs. "supposedly thoroughly security audited" Audited, as in past tense is useless. How about continual auditing. That is the way OpenBSD treats their code. It is constantly in a process of audit. That being the case, they are constantly refining that code, fixing potential sources of instability, and the occasional potential exploit. Auditing code is an ongoing process as those that would try to exploit code find new ways in. As far as your assertion that "blackhats have been able to find and exploit so many holes", it just isn't true. OpenBSD is about as secure as they come. You're spouting vitriolic nonsense to insight some os holy war.