Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

OpenSSH 4.2 released

Hemos posted more than 9 years ago | from the becoming-more-secure dept.

Upgrades 183

BSDForums writes "OpenSSH 4.2 has been released. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. Changes since OpenSSH 4.1 include security bug fixes relating to GatewayPorts, and GSSAPI, which eliminates the risk of credentials being inadvertently exposed to an untrusted user/host. A new compression method, proactive changes for signed vs. unsigned integer bugs, and many additional bugfixes and improvements highlight this release."

Sorry! There are no comments related to the filter you selected.

uh oh (0)

dave420 (699308) | more than 9 years ago | (#13483528)

"proactive".

Obvious solution to the eMarket-demands (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#13483630)

We need to embrace revolutionary channels, grow cross-platform web services,
incubate revolutionary ROI, transition web-enabled partnerships, synthesize
enterprise eyeballs, brand intuitive e-tailers, enhance holistic e-business,
enhance integrated schemas, monetize enterprise convergence, syndicate
next-generation metrics, architect dot-com initiatives, cultivate global
markets, leverage vertical schemas, morph integrated action-items, scale
synergistic content, harness collaborative communities, leverage world-class
e-markets, recontextualize integrated partnerships, unleash clicks-and-mortar
metrics, recontextualize collaborative schemas, scale out-of-the-box content,
unleash leading-edge synergies, expedite open-source action-items, iterate
global channels, engage transparent e-tailers, harness distributed
supply-chains, extend efficient paradigms, enable world-class e-markets,
repurpose dynamic users and whiteboard 24/7 e-tailers.

The new compression method is pretty fantastic. (4, Informative)

CyricZ (887944) | more than 9 years ago | (#13483532)

I've found that it offers a good 10% to 15% decrease in data size compared to the previous method.

Re:The new compression method is pretty fantastic. (4, Insightful)

nurb432 (527695) | more than 9 years ago | (#13483545)

That might make remote X11 useable on a cable modem..

Speaking of X11-related improvements... (4, Informative)

CyricZ (887944) | more than 9 years ago | (#13483581)

From the changelog:
- Implemented support for X11 and agent forwarding over multiplexed connections. Because of protocol limitations, the slave connections inherit the master's DISPLAY and SSH_AUTH_SOCK rather than distinctly forwarding their own.

This bugfix may very well affect the performance of OpenSSH when used to encrypt communications with a remote X11 server.

Just use NX (2, Informative)

vlad_petric (94134) | more than 9 years ago | (#13483779)

if you don't want to pay for the nomachine license, freenx is pretty decent.

Re:Just use NX (1)

nurb432 (527695) | more than 9 years ago | (#13483825)

I havent managed to get it working under freebsd yet..

But it does look like its got promise. I tried the demo once, and was impressed.

Re:The new compression method is pretty fantastic. (1)

suitepotato (863945) | more than 9 years ago | (#13483908)

That might make remote X11 useable on a cable modem..

It already is useable at the current top speeds which are now several megabits upstream and ten to fifteen down, depending on where you live. Even at 512Kbps upstream it is useable for me in concert with VNC.

Re:The new compression method is pretty fantastic. (1)

cerelib (903469) | more than 9 years ago | (#13483984)

Are you using vnc to control an X desktop? Because to my knowledge that is different than using remote X applications which I have always found to be slow.

Re:The new compression method is pretty fantastic. (1)

nurb432 (527695) | more than 9 years ago | (#13484036)

Due to the speed of remote X across my cable wire, i am using VNC ( via SSH ) to get by. ( with VNC running as a daemon off inetd )

But, its a bit overkill and isnt as seemless as id like it.

Re:The new compression method is pretty fantastic. (1)

nurb432 (527695) | more than 9 years ago | (#13484089)

I'm capped at 128k upstream here...

VNC works with 128K to get a desktop, but id rather use native X11. ( seemless windows, cut/paste to the local machine, etc etc )

But they didn't add new compression (5, Informative)

BobPaul (710574) | more than 9 years ago | (#13483595)

From the changelog:
" Added a new compression method that delays the start of zlib compression until the user has been authenticated successfully. The new method ("Compression delayed") is on by default in the server. This eliminates the risk of any zlib vulnerability leading to a compromise of the server from unauthenticated users." (emphasis mine)

OpenSSH used zlib before, and they're still using it now. All they've done is delay the start of compressed streams until after authentication. This is a security fix, not a speed boost.

Re:The new compression method is pretty fantastic. (1)

Titus B. Otch (912256) | more than 9 years ago | (#13483605)

FTA: Added a new compression method that delays the start of zlib compression until the user has been authenticated successfully."

Who care's about compression algo(s). SSH was designed with security in mind, and it's about time they add this pause, since who really knows what's up wif zlib these days...

Compression algorithms do matter. (2, Interesting)

CyricZ (887944) | more than 9 years ago | (#13483694)

Compression algorithms matter quite a bit. Remember, if you can save even 100 bytes for every second of data flow, that adds up quickly. That's 6000 bytes/minute. That's 360000 bytes/hour. That's 8640000 bytes/day. Over the course of a year you'd save around 3 GB. That can very well impact on bandwidth costs when multiplied by several (if not hundreds of) users.

It's factors like that which make OpenSSL, especially OpenSSL 4.2, very appealing to network administrators who must take into account bandwidth costs.

Re:Compression algorithms do matter. (0)

Anonymous Coward | more than 9 years ago | (#13485023)

It's factors like that which make OpenSSL, especially OpenSSL 4.2, very appealing to network administrators who must take into account bandwidth costs.

I think you mean OpenSSH.

Compression algorithms matter quite a bit. Remember, if you can save even 100 bytes for every second of data flow, that adds up quickly.

The bandwidth savings are minor. Many (most?) ssh connections are command line sessions, that are very low bandwidth to begin with.

Only when moving a lot of data over ssh would this savings appear, and zlib was already pretty good.

And for port-forwarding, other techniques like ssl are more efficient than the tcp-on-tcp of ssh port forwarding.

Mod down (0)

Anonymous Coward | more than 9 years ago | (#13483642)

Post is bollocks - "new" compression method is a security fix, not a functional improvement.

Alternative to X - NX (0, Offtopic)

La Gris (531858) | more than 9 years ago | (#13483697)

You realy should have a look a FreeNX http://freshmeat.net/projects/freenx/>
FreeNX Server is the Free and GPL'd NX server implementation by Fabian Franz, based on NoMachine.com's NX technology. NoMachine have thankfully licensed the core of NX under the GPL (they provide a close-source commercial NX server product on top of that code, as well as professional support).

The NX protocol let you use remote X display while connected by low bandwidth lines. It require much less bandwith than raw X or X over compressed ssh.

Re:The new compression method is pretty fantastic. (1)

Sarin (112173) | more than 9 years ago | (#13483905)

Compression and portforwarding is a golden combination.
You can login into your providers ssh server (if they have that) and forward/compress the port of your favourite usenet server. That way I had a 300kb/sec speed boost - I got more data than my adsl account normally could handle. Maybe with this compression boost there's even room for more bandwidth on my 8mbit account.
I'll bet my provider's going to be even more happy with me again.

Increased default key size. (4, Interesting)

CyricZ (887944) | more than 9 years ago | (#13483546)

From the changelog:
"- Increase the default size of new RSA/DSA keys generated by ssh-keygen from 1024 to 2048 bits."

It's good to see that the default size of the keys had been increased. It's only a matter of time before modern systems (or clusters of modern systems) are capable of defeating even 1024 bit keys routinely. This proactive doubling of the default keysize is sure to increase the overall security for OpenSSH users for some time.

Re:Increased default key size. (1, Interesting)

Anonymous Coward | more than 9 years ago | (#13483597)

The increase of the key size might not be as useful as you think. The best way to get through these encryptions has been, and will continue to be non-brute force methods including social engineering or other methods of obtaining the key. The increase in computing systems does not actually get us much closer to cracking it considering by best methods availible it would still take my computer more then 10^50 years (if memory servers me right) to crack a 1024 bit key. There would have to be a very significant increase in the level of computing power before this becomes plausable. The biggest worry here is in case mathematicall methods of increase efficenecy are developed that increase cracking time without completely breaking the code.

Re:Increased default key size. (1)

CyricZ (887944) | more than 9 years ago | (#13483613)

Changes are your computer is hardly the bastion of computing systems. But it's naive to believe that there will not be major increases in computing capabilities, even within the next few years. What today seems impossible with regards to computing will be sitting on your desk. And a couple of years later it will be in your closet collecting dust, replaced by the next computing innovation. Soon enough, a child will have a toy portable gaming system that is powerful enough to crack 1024-bit keys within seconds.

Social engineering will most likely remain constant. Hence the increase in key size will only serve to increase security, at least for the time being.

Re:Increased default key size. (0)

Anonymous Coward | more than 9 years ago | (#13483878)

Maybe you don't realize how big 10^50 is. Even if you have a computer a million times more powerful than his and even if computing power increases a million fold (current rate is doubling every 18 months and that is expected to taper off), every single star in the universe will die off before you finish cracking it (actually you'll still be trying to crack it when the last star dies).

Re:Increased default key size. (0)

Anonymous Coward | more than 9 years ago | (#13484139)

Cracking it on the first attempt and cracking it on the 10^50th attempt have equal probabilities.

Re:Increased default key size. (4, Insightful)

h4rm0ny (722443) | more than 9 years ago | (#13484668)


Cracking it on the first attempt and cracking it on the 10^50th attempt have equal probabilities.

True, but both probabilities are minute. The median of that range is 5*10^49 meaning that's the average number of tries you need. If you got lucky and found it in the first 10%, that's 10^49. If someone wanting to spy on you can muster the resources to crack that in a human lifetime, you've made an enemy of God!

Quantum computing opens up some interesting possibilities, but if a hypothetical Quantum computer in the year 2015 could search 1x10^23 keys per second (more than that massive distributed Internet project a while ago), it would still take millions of years on average.

10^50 is a big number.

Re:Increased default key size. (4, Informative)

Kjella (173770) | more than 9 years ago | (#13484093)

1024 bit asymmetric is roughly as hard to crack as 128 bit symmetric = ~10^40. It's *still* on the order of "If we take all the power of the sun to power PIVs we can do it" level. Noting that I'm talking about instructions/watt here (energy efficiency), not instructions/second (speed). Obviously you get a lot better dedicated chips than that, but even so... unless you're Osama, you needn't worry.

Moving to 2048 bits is the kind of "Even if you take the power of the sun and the whole galaxy too, and run it on hyperefficient nanowatt CPUs that can do one key/clock cycle, you're still going to run out of energy" move. Unless you happen to know a better algorithm than brute force, in which case 2048 bits may be just as screwed as 1024 bits...

Kjella

Re:Increased default key size. (2, Insightful)

Malor (3658) | more than 9 years ago | (#13484174)

As far as I know, the computational overhead of the higher-bit keys isn't that significant, so it's probably not doing any actual harm. It'll slow down initial key negotiation and session setup, but it shouldn't affect traffic overhead, because that's encrypted with a symmetric cipher that was negotiated with the (very slow) public-key protocol. You'd probably only notice the overhead if you were running a server with many, many session setups. If it impacted you, generating a smaller key would be trivial.

The larger key will make your data more secure on the wire, in transit, but the weakest point has always been the key's passphrase. A 32768-bit key is just as crackable as a 256-bit key if you have physical access to the encrypted keyfile.

Improving transit security isn't an inherently bad idea, but it's making the strongest link in the chain even stronger. It probably won't do that much to increase overall security.

Re:Increased default key size. (1)

Homology (639438) | more than 9 years ago | (#13484299)

As far as I know, the computational overhead of the higher-bit keys isn't that significant, so it's probably not doing any actual harm. It'll slow down initial key negotiation and session setup, but it shouldn't affect traffic overhead, because that's encrypted with a symmetric cipher that was negotiated with the (very slow) public-key protocol.

The generation of server keys will take _much_ longer time on some architectures, and this was actually one of the arguments of not increasing the key length earier. Of course, 1024 was considered "safe enough", though.

Re:Increased default key size. (1)

Malor (3658) | more than 9 years ago | (#13484517)

Definitely correct, but you only do that once, normally. Is an extra five minutes at server build really that big a deal?

Longer passwords on UnixWare? (3, Interesting)

CyricZ (887944) | more than 9 years ago | (#13483562)

From the changelog:
- Portable OpenSSH: Added support for long passwords (> 8-char) on UnixWare 7.

I'm surprised that it has taken them this long to add support for long passwords to UnixWare 7. UnixWare 7 is a modern UNIX by all means, considering it is still being updated frequently. Can anybody shed some light as to why it took so long for this fairly rudimentary support to be added to the portable version of OpenSSH?

Re:Longer passwords on UnixWare? (1)

LurkerXXX (667952) | more than 9 years ago | (#13483741)

Just a guess but, maybe a lack of someone working on OpenSSH who actually uses UnixWare 7?

Re:Longer passwords on UnixWare? (0)

Anonymous Coward | more than 9 years ago | (#13484313)

Northwestern University still limits our school-wide passwords to 6-8 characters. Shame on them. (At least the CS Dept passwords aren't artificially crippled this way.)

Please excuse my obvious ass-kissing (2)

xiando (770382) | more than 9 years ago | (#13483568)

A new version of my favorite Linux tool! How great! I could not live a second without being able to scp file.tar.bz2 user@hostname:/path, or without being able to open files remotely using KDEs fish: fish://username:passord@host.box/some/path works in all the KDE file dialog boxes thanks to SSH. Nor would I be able to login to the box where I have my irssi IRC client running, connected to numerous IRC servers and a BitlBee gateway for MSN/ICQ/AIM/Google Talk. And then there is sftp.. SSH is something completely essential for most experienced Linux-users, used one way or the other constantly when I am in front of my computer. So thank you, SSH developers, for making my life better! And thank you for a new, more secure version.

Re:Please excuse my obvious ass-kissing (-1, Troll)

Anonymous Coward | more than 9 years ago | (#13483596)

fucking jews

Re:Please excuse my obvious ass-kissing (5, Informative)

ScriptedReplay (908196) | more than 9 years ago | (#13483657)

Hint: use aliases in .ssh/config to make your life easier. Something like:

Host alias1
      Hostname hostname
      User username
      [add extra options like authentication method, X11 forwarding, agent forwarding, private key to use and so on]

then you do scp file.tar.bz2 alias1/path or fish://alias1/some/path (and get a password prompt). Less typing - and works with bash completion too.

Re:Please excuse my obvious ass-kissing (0)

fimbulvetr (598306) | more than 9 years ago | (#13483707)

You are a saviour!!!!!

I've always wondered if it did this, but I've been too lazy to check.

Re:Please excuse my obvious ass-kissing (4, Insightful)

Kynde (324134) | more than 9 years ago | (#13483861)

Bloody hell. I've been using openssh ever since it came out and quite a while the old Tatu Ylönen's ssh before that and type all those lengthy user@hostname.domainname.whatever: prefixes day in day out without knowing about those aliases.

The fact is that in OSS world one should, atleast once a month raise fingers from the keyboard and stop to think "What am I missing from my daily environment? Are stupid, repetetive or borings things that I do all too frequently?". The odds are that I could easily fix most of them swiftly and the ones that might require moderate amounts of work to happen it's quite likely that someone hast stumbled on those very same issues before me and fixed them. (and experience in *nix world teaches me that frequently the fix is quite brilliant)

Re:Please excuse my obvious ass-kissing (1)

Homology (639438) | more than 9 years ago | (#13484328)

Funnily enough, in the responses to the upcoming BSD certifiction, some of the respondents said that skilled/expert administrators should not have to look in the man pages. But if this is the attitude, my guess is that they don't read man pages very often, and thus miss all the new fun stuff :-)

Re:Please excuse my obvious ass-kissing (1)

sponger (96171) | more than 9 years ago | (#13484646)

I agree! what else are they there for? even Lawyers refer to lawbooks.

Re:Please excuse my obvious ass-kissing (1)

pAnkRat (639452) | more than 9 years ago | (#13484389)

-- atleast once a month raise fingers from the keyboard and stop to think "What am I missing from my daily environment? Are stupid, repetetive or borings things that I do all too frequently?". ..

Yep, that's what I do all day.
Problem is that I don't get any real work done, but that's another story :-)

Re:Please excuse my obvious ass-kissing (0)

Anonymous Coward | more than 9 years ago | (#13483701)

A new version of my favorite Linux tool! How great!

It is actually an OpenBSD tool. Linux is only a kernel.

Re:Please excuse my obvious ass-kissing (2, Interesting)

thc69 (98798) | more than 9 years ago | (#13483775)

The coolest thing about ssh is the versatility you get out of one open port. You can login, cp, and ftp securely, with only one port open; additionally, you can tunnel any other port you want. ssh is great for securing vnc.

It's not even hard to find a client. Modern Linux and BSD systems mostly have it, and if you're using Windows, you can download PuTTY and use it without even having to install it and make a mess. Great if you're a guest on somebody else's system.

I use ssh, sftp, scp, and vnc over ssh daily.

Re:Please excuse my obvious ass-kissing (0)

Anonymous Coward | more than 9 years ago | (#13484038)

Personally I'd live much better with plan9-like operative systems, where you don't "scp" things, but import/export directories to your own process' filesystem namespace and then use cp, etc...

Why you shouldn't use OpenSSH (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#13483572)

A key member of the OpenSSH team is Theo DeRaadt, and Theo has done more to hurt open source than any other single person. How can one person do so much damage? By being a complete and total asshole.

Think this is a joke? Think that surely no one could be THAT much of an asshole? Google around. Read some mailing list archives. The guy is KING asshole.

Re:Why you shouldn't use OpenSSH (5, Insightful)

CyricZ (887944) | more than 9 years ago | (#13483602)

There is no question that Mr. deRaadt is quite outspoken. But he can produce some damn fine and mighty secure code. I have nothing but the utmost respect for his coding abilities, even if his public relations skill are lacking.

Frankly, I'd rather put up with arrogance and have access to amazing code, rather than dealing with a nice person who can't write code worthy of a cockfool.

Re:Why you shouldn't use OpenSSH (1, Offtopic)

Elektroschock (659467) | more than 9 years ago | (#13483732)

wikipedia article "After de Raadt stated his disapproval of the U.S.-led occupation of Iraq in an interview with Toronto's Globe and Mail, a multi-million-dollar US Department of Defense grant to the University of Pennsylvania's POSSE project was cancelled, effectively ending the project. Funding from the grant had been used in the development of OpenSSH and OpenBSD, as well as many other projects and was to be used to pay for the hackathon planned for the May 8, 2003. Despite money from the grant already having been used to secure accommodations for 60 developers for a week, the money was reclaimed by the government at a loss and the hotel told to not allow the developers to pay the reclaimed money to resecure the rooms. This resulted in criticism among some that the US military held an anti-free speech attitude."

What's bad about doing THE RIGHT THING? Even if you have to pay the price. This is what we want from a security specialist.

Is this solution secure? -->
specialist: Well, blabla...quantum computing...
marketing guy: Absolutely!

Go to Iraq? --> ...

A trustful security specialist has to tell you the truth. Diplomacy serves stupidity and insecurity.

Military systems want "loyality", they do not want you to talk about problems, they want you to report that everything's fine. Because when you talk about problems it means work for them. That is why they fail, why they are dysfunctional from an organisational perspective. Dictorship simply means: organise the state like the military system. but the fact is: Problems make life intresting. Problems are no shame. Shutting down discussions about them does not solve them. Think negative!

Re:Why you shouldn't use OpenSSH (1)

fbg111 (529550) | more than 9 years ago | (#13484825)

Frankly, I'd rather put up with arrogance and have access to amazing code, rather than dealing with a nice person who can't write code worthy of a cockfool.

Fortunately, decency and skill/talent are not mutually exclusive, and there are plenty of examples of that, so it's not too much to ask even of brilliant people that they also comport as decent human beings.

Re:Why you shouldn't use OpenSSH (1, Flamebait)

Elektroschock (659467) | more than 9 years ago | (#13483639)

What "damage" did he do to Open source?

He annoys people. ...well...He is probably an asperger.

Re:Why you shouldn't use OpenSSH (0)

Anonymous Coward | more than 9 years ago | (#13483759)

Why flamebait? It's a simple speculation. It's not like it's an insult. If anything it's a reasonable explanation to, and to be honest somewhat of an excuse for, his behaviour.

Re:Why you shouldn't use OpenSSH (2, Insightful)

Elektroschock (659467) | more than 9 years ago | (#13483823)

Talented people, real genius, think of Mozart and others... they are usually a little bit mad and they deserve tolerance.

They can take the freedom to be different and we have to understand that we have to adopt to them.

Re:Why you shouldn't use OpenSSH (1)

TheRaven64 (641858) | more than 9 years ago | (#13483947)

Read Theo when he's actually allowed to talk without being baited. I read a long interview in the Sydney Morning Herald about a year ago, which was a strong influence in making me start using OpenBSD. The impression he gave was of someone who doesn't take any bullshit, but who is incredibly competent - exactly the person I would pick as project leader for an OS I was going to use.

The OpenBSD community does tend to be a bit arrogant, but that's what you get from developing an OS which considers free-as-in-RMS to be just about free enough at a push, and which gets used to security advisories being tagged as `does not apply on OpenBSD'.

Re:Why you shouldn't use OpenSSH (2, Insightful)

Yaa 101 (664725) | more than 9 years ago | (#13483683)

Theo de Raadt is ok really, he puts his coding where his mouth is. And at least he's not a corporate ass-licker like a lot of others. He does not corrupt his vision with corporate goodies.

Re:Why you shouldn't use OpenSSH (0)

Anonymous Coward | more than 9 years ago | (#13483687)

Where can I download your OpenSSH replacement ?

Re:Why you shouldn't use OpenSSH (1)

Krunch (704330) | more than 9 years ago | (#13483782)

Here [0xbadc0de.be] . Notice I'm not the parent poster and I don't really care about De Raadt's attitude (and I use OpenSSH and OpenBSD daily and I have never tried libssh, I just know it exists).

Re:Why you shouldn't use OpenSSH (0)

Anonymous Coward | more than 9 years ago | (#13483711)

I don't really care about the politics. Maybe that is something I would take in consderation if I wanted to be his friend and have him around people I know, but why does it matter when it comes to using his code?

What I do know is that OpenSSH is a fine piece of software and it gets put on all of my servers. I'll be happy to know that Theo's code is in there.

Re:Why you shouldn't use OpenSSH (3, Insightful)

slavemowgli (585321) | more than 9 years ago | (#13483713)

Admittedly, yes, Theo is (or at least can be) quite an asshole. But what does that have to do with the quality of OpenSSH (or OpenBSD)?

Like him or not, but it's a great program, and not using it just because you don't like the lead developer, when there are no actual reasons not to, is stupid.

Which idiot makes this insightfull? (4, Insightful)

Yaa 101 (664725) | more than 9 years ago | (#13483714)

So we must stop using one of the worlds best security software because somebody does not like Theo de Raadt?

Are you mod fucking insane?

Re:Which idiot makes this insightfull? (0, Offtopic)

Homology (639438) | more than 9 years ago | (#13483876)

So we must stop using one of the worlds best security software because somebody does not like Theo de Raadt?

Are you mod fucking insane?

There are also many moderators that abuse the moderation system by modding down posts they don't agree with. It's so rampant that I usually meta moderate troll/flamebait as unfair.

Re:Why you shouldn't use OpenSSH (2, Insightful)

Ann Elk (668880) | more than 9 years ago | (#13483722)

As a friend of mine says, "It's OK if they call you an asshole, if they say it with awe."

Theo is certainly opinionated, and he may or may not be an asshole, but his group produces some damn fine software. You may not like his methods, but it's difficult to argue with his results.

Re:Why you shouldn't use OpenSSH (3, Insightful)

ArbitraryConstant (763964) | more than 9 years ago | (#13483764)

I've met Stallman and de Raadt and they're both assholes. But the world needs a few people that are willing to be assholes.

He gets results. For example, giving out contact information isn't the nicest way to get hardware docs and firmware, but it works.

Re:Why you shouldn't use OpenSSH (1)

Homology (639438) | more than 9 years ago | (#13483909)

I've met Stallman and de Raadt and they're both assholes. But the world needs a few people that are willing to be assholes.

He gets results. For example, giving out contact information isn't the nicest way to get hardware docs and firmware, but it works.

de Raadt only releases contact information when everything else has failed for several months. The latest incident with Adaptec is an example of this.

Re:Why you shouldn't use OpenSSH (0)

Anonymous Coward | more than 9 years ago | (#13484764)

You're thinking of Poul-Henning Kamp and Dag-Erling Smorgrav from the FreeBSD arrogant asshole team.

From Bill Gates... (3, Funny)

Anonymous Coward | more than 9 years ago | (#13483618)

I'll take that, thanks!

Keep up the good work guys.

It's our pleasure, Mr. Gates. (2, Insightful)

CyricZ (887944) | more than 9 years ago | (#13483629)

No problem, Bill. After all, open source software (especially that under the BSD license) is meant to be shared and used by all, basically however they see fit. That's the name of the game, Mr. Gates.

Re:It's our pleasure, Mr. Gates. (4, Insightful)

ArbitraryConstant (763964) | more than 9 years ago | (#13483724)

The BSD licensing has made it possible for commercial OSes to have an SSH implementation by default. That ubiquity is what killed telnet. By helping companies like Microsoft, Sun, and Apple, the OpenSSH project has helped everyone.

Re:It's our pleasure, Mr. Gates. (1)

einhe1t (900548) | more than 9 years ago | (#13484760)

How has openssh helped microsoft?

I don't remember seeing ssh in mswindoze by default. Hell, ms only recently started offering telnet -

Still no logging of sftp/scp transfers? (2, Insightful)

GeekBoy (10877) | more than 9 years ago | (#13483665)

Sigh. Back to my commercial (vandyke vshelld) implementation....

Re:Still no logging of sftp/scp transfers? (0)

Anonymous Coward | more than 9 years ago | (#13483692)

Umm.. I get log notices for sftp/scp transfers /w OpenSSH.

Re:Still no logging of sftp/scp transfers? (1)

slavemowgli (585321) | more than 9 years ago | (#13483726)

Why not just implement it? I'm not that familiar with C really, but I'd be surprised if it was more than a few lines - basically, you'd just have to add a call to syslog(3) in an appropriate place.

Re:Still no logging of sftp/scp transfers? (5, Informative)

incubuz1980 (450713) | more than 9 years ago | (#13483786)


http://sftplogging.sourceforge.net/ [sourceforge.net]

Don't know if i works against OpenSSH 4.2.

But it probably will soon.

Re:Still no logging of sftp/scp transfers? (0)

Anonymous Coward | more than 9 years ago | (#13483809)

google + "sftp log" = you are an assclown!

http://sftplogging.sourceforge.net/ [sourceforge.net]
This patch adds the following functionality to openssh:

        * Log FTP Sessions
        * Designate a umask for FTP sessions
        * Allow/disallow "chown" or "chgrp" during FTP Sessions

Re:Still no logging of sftp/scp transfers? (1)

GeekBoy (10877) | more than 9 years ago | (#13484937)

And is is part of the standard distro? No. What is that important? b/c of our support agreements. RedHat will only support unmodified binaries that come with their distro. RedHat and it's support are required by my client.

Re:Still no logging of sftp/scp transfers? (2, Insightful)

RAMMS+EIN (578166) | more than 9 years ago | (#13483844)

As far as I understand, both scp and sftp are actually implemented by separate binaries on the server side. Why don't you just replace those binaries with ones that do your logging and defer the actual work to the original binaries?

Re:Still no logging of sftp/scp transfers? (1)

brenddie (897982) | more than 9 years ago | (#13483900)

I use vandyke vshell too.
Very robust product. The most usefull features are loggin of transfers, download/upload triggers, and disabling of shell/sftp by groups.
Very secure , Only 1 Security Advisory (august 2005) in a couple years

Slowing down dictionary attacks (5, Informative)

RAMMS+EIN (578166) | more than 9 years ago | (#13483804)

I had an instance of an attacker running a dictionary attack on my sshd the other day, and I was surprised by how many logins he could test per second (he was using multiple connections). I asked on #openbsd about ways of slowing down such attacks. This is the advice I got:

1. Run sshd on a different port. The scripts won't find you there. I don't like this option, because it requires me to specify the alternative port every time i ssh, scp, rsync, or svn. It's still about the easiest and most effective method.

2. Limit the connection rate to the port you're running sshd on. In many scenarios, it won't hurt you if you can't connect to it more than once in 5 seconds, but this will make a dictionary attack from a single machine very tedious. In OpenBSD 3.7, you can use pf with max-src-conn-rate.

3. Use a script like DenyHosts [sourceforge.net] to monitor your authentication log, and add suspicious hosts to a block list (either temporarily or permanently). This looks like a very nice solution to me.

4. I got this one from my girlfriend: disable password authentication and use key-based authentication instead. This is my prefered solution, except that I have to solve some problems with public key authentication not working from some of the machines I use.

I hope this post is helpful to some of you. If you have any other methods that you would like to mention, I'd be glad to hear.

Re:Slowing down dictionary attacks (1, Interesting)

Anonymous Coward | more than 9 years ago | (#13483849)

UNIX has had exponential backoffs forever. Mess up one time, you get a 1 second delay. Mess up twice, you get to wait 2 seconds, etc. I wonder why that couldn't be done in an ssh context.

Re:Slowing down dictionary attacks (4, Insightful)

RAMMS+EIN (578166) | more than 9 years ago | (#13483975)

``UNIX has had exponential backoffs forever. Mess up one time, you get a 1 second delay. Mess up twice, you get to wait 2 seconds, etc. I wonder why that couldn't be done in an ssh context.''

This exponential backoff system works when you're trying to log in from a tty. When SSH, the system doesn't know whether this is the same user trying to authenticate. It's similar to sitting in front of a Linux box, trying to log in on VT 1, and when it backs off, switch to VT 2, and so on.

The situation could be improved somewhat by sshd tracking failed logins by IP address, and disallowing that IP address from logging in for a while. However, this complicates sshd and isn't really bullet proof, what with NAT making any number of machines appear to have the same IP address.

Re:Slowing down dictionary attacks (1)

Just Some Guy (3352) | more than 9 years ago | (#13483872)

I got this one from my girlfriend: disable password authentication and use key-based authentication instead. This is my prefered solution, except that I have to solve some problems with public key authentication not working from some of the machines I use.

Your girlfriend rocks. I always disable password authentication on a new server before I enable sshd for the first time. I'm pretty certain I could safely give my root password out on IRC without much risk, although prudence says I'm not completely interested in testing that theory.

What sort of problems do you have with public key authentication? I've been using it for years from both Unix and Windows clients without problem. If you're feeling particularly 1337, GSSAPI authentication is pretty darn convenient and not all that hard to configure these days.

Re:Slowing down dictionary attacks (2, Informative)

RAMMS+EIN (578166) | more than 9 years ago | (#13484151)

``Your girlfriend rocks.''

Yes, totally. I feel the luckiest guy in the world for having a girlfriend who's a hacker, too.

``What sort of problems do you have with public key authentication?''

From some machines, it just doesn't seem to use it. If I run ssh with -vv, it gives some messages about "we did not send a packet", then tries password auth instead. I don't have access to such a machine at the moment, otherwise I would be more specific.

Re:Slowing down dictionary attacks (1)

irc.goatse.cx troll (593289) | more than 9 years ago | (#13484510)

I've ran into that atleast once before, but even additionally I'd never want to entirely disable password auth because then what if something happens to your privkey? Think katrina-sized destruction taking out your computer/entire house + the bank that housed your backup usb thumbdrive.
Or even a more realistic scenario, sometimes you just want someone else to be able to log into your machine, be it a friend helping you or even an admin at a datacenter that doesnt want to have to dig out a keyboard+monitor to do a local login.

Re:I get a truckload of dictionary attacks (2, Interesting)

xiando (770382) | more than 9 years ago | (#13483910)

..on any given day.

Box #1:
grep "authentication failure"
/var/log/messages|wc -l
1362

Box #2:
grep "authentication failure" /var/log/messages|wc -l
1520

Thank you very much for more great SSH tips, I hope you do not mind I recycled them at http://en.linuxreviews.org/Ssh [linuxreviews.org] (it is a wiki, so I can easily remove your work if you mind, or you can do it..) :-)

Re:I get a truckload of dictionary attacks (1)

RAMMS+EIN (578166) | more than 9 years ago | (#13484008)

``I hope you do not mind I recycled them at http://en.linuxreviews.org/Ssh [linuxreviews.org] ''

I most certainly don't mind, otherwise I wouldn't have posted them here. You might want to change the wording, though. It sounds a bit strange the way it stands. If you do that, could you also change the link to my site to read "inglorion" instead of "Bob"; I prefer to use my handle rather than my name when it's not about personal communication.

Anyway, thanks for putting it there!

DenyHosts alternative. (1)

eddy (18759) | more than 9 years ago | (#13484045)

Didn't know about DenyHosts, wrote something similar in sshd_failed_ips.pl [gazonk.org] . I didn't want a deamon or cron job when it's completely unnecessary, though me script does depend on TCP wrappers (any dist. not running that by default?)

Re:Slowing down dictionary attacks (5, Informative)

jsveiga (465473) | more than 9 years ago | (#13484118)

For your item "2", on Linux, you can use iptables "recent" module to limit the time between new connections from the same IP. That cut the dictionary attacks on my server on the first attempt:

iptables -A INPUT -j ACCEPT -p tcp ! --syn -s 0/0 -d (outer ip/net)
(you probably have this on your firewall already, allowing previously established connections)

iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent --update --seconds 15 -j DROP
iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent --set -j ACCEPT

These two will only allow new connections from the same IP with 15s intervals between them. Add them to your iptables setup scripts (or replace them where you ACCEPT ssh, if that's the case).

BR,

Joao S Veiga

Re:Slowing down dictionary attacks (1)

Realistic_Dragon (655151) | more than 9 years ago | (#13484305)

You can always use two SSH demons - one on port 22 that allows only connections with certificates, and one on port rand# that is limited to few retries per second, then a short ban after a few bad attempts, but otherwise normal logins.

Re:Slowing down dictionary attacks (2, Informative)

lmfr (567586) | more than 9 years ago | (#13484367)

1. Run sshd on a different port. The scripts won't find you there. I don't like this option, because it requires me to specify the alternative port every time i ssh, scp, rsync, or svn. It's still about the easiest and most effective method.

No need to specify the port every time on the comand line. Edit one of /etc/ssh_config, /etc/ssh/ssh_config or ~/.ssh/config, and add the configuration:
Host *
Port new_port

That changes the default for every host, so you'll probably decide to define only for your hosts (Host myhost).

Re:Slowing down dictionary attacks (0)

Anonymous Coward | more than 9 years ago | (#13484448)

Holy crap, you are one lucky geek. You have a girlfriend who understands SSH and digs public-key encryption. Now you just need her to probe your ports ;-)

Re:Slowing down dictionary attacks (0)

Anonymous Coward | more than 9 years ago | (#13484488)

You could try using OTP as a fallback to key authentication, though I don't know if that'll improve your situation by much. (still safer then typing a regular password, though)

Re:Slowing down dictionary attacks (0)

Anonymous Coward | more than 9 years ago | (#13485055)

I was looking at a solution like your #3 (DenyHosts), but although it would be effective against dictionary and brute-force attacks it offers no protection against a newly-discovered or unpatched security flaw in the OpenSSH server.

I kept looking and fell in love with port knocking. There are many implementations and variations on the concept floating around, but the single best source of information that I found is at http://www.portknocking.org/ [portknocking.org] which in addition to an entire education on the topic, offers a very good free Perl implementation that the author walks you through the workings of, plus links to many other implentations.

The drawback to this is that you need to keep available a port knocking client in addition to an ssh client, which may be awkward if you need to connect from many different workstations (or especially while traveling), or if you have many users who need to connect.

-d option for scp? (1)

Wills (242929) | more than 9 years ago | (#13483848)

I'd really like to see a -d option added to scp for copying symbolic links as symbolic links rather than the files to which the sym.links point. The cp command has it (see man cp for details).

As a workaround you can wrap all the remote files in a temporary tar file to protect any sym.links etc, then scp the tar file and untar the tar file after the transfer but it would be much quicker and simpler if you could use scp to do this.

Re:-d option for scp? (1, Informative)

Anonymous Coward | more than 9 years ago | (#13483946)

or you could just use rsync over ssh instead

Re:-d option for scp? (1)

Wills (242929) | more than 9 years ago | (#13484011)

Thanks, that's another good way of doing the same thing. My point is simply that it would be more convenient to have a -d option in scp but it's certainly not an essential thing to have in view of the many workarounds that are available.

Re:-d option for scp? (5, Informative)

Jerf (17166) | more than 9 years ago | (#13483987)

Leaning on tar is probably a better solution anyhow.

I don't know your exact needs, but you can make this easy on yourself with a very short shell script, or even just an alias. Instead of using "scp", use "ssh" directly, something like:
ssh [your login here] -C 'tar c $*' | tar x
This runs "tar" on the remote server, $* is trying to convey the idea of passing all the params of the script/alias to the remote tar, and outputs to stdout. ssh redirects stdout across the network to its own stdout, which is then piped to local tar for extraction. -C compresses the stream, which is probably Good Enough, but under certain circumstances (CPU time vastly outweighs transfer time, think modem transfer here) it can be worthwhile to add bzip2 into the mix:
ssh [your login] 'tar c $* | bzip2' | bunzip2 | tar x
Tune the script to your needs, and the reverse script is pretty easy too; ssh will redirect its stdin across the network just as easily if you use it in a pipe.

Note there is never a temporary file.

I belabor how this works because it took me a while to fully grasp how cool it is that ssh makes the Unix pipe idea fully work across the network. Note you can set up pipes on the remote side in the ssh command if you escape it correctly (apostrophes will usually do, but shell escaping can get evil). scp is more "convenience script" than "fundamental tool".

Re:-d option for scp? (1)

Wills (242929) | more than 9 years ago | (#13484200)

Thanks, that's a good method for certain situations. However, having a -d option in scp, thus avoiding the need to use any external helper programs like tar and rsync, would be even more convenient in general. It would also have the benefit of making scp more similar to cp.

The current workarounds for not having a -d option in scp tend to be problematic in various ways. For example, using tar becomes quite tedious when you want to copy only files in a particular directory, without recursively copying any sub-directories and their contents.

Another issue is that using a script or alias to run the tar command causes it to be re-run from scratch every time the script gets re-started following an interruption, e.g. a network problem, which can be extremely wasteful when copying large numbers of files, compared to using a carefully implemented -d option in scp which could reasonably decide not to copy files again that already exist at the destination, e.g. because they were previously successfully copied, unless you request scp -f to forcefully copy the files again, clobbering the existing destination files.

Having a -d option in scp is obviously not anything like a critical need. It would be simply be very handy and logical by comparison with cp to have that functionality inside a single command.

GSSAPI (4, Informative)

Craig Ringer (302899) | more than 9 years ago | (#13483869)

GSSAPI, in case anyone here is unfamiliar with the term, is pretty much Kerberos 5. It's a key-based network authentication and security scheme used on many UNIX networks, and in a bastardised form by Windows AD domains.

It's also been on my "I really must implement that" list for waaaay too long. I find that more basic TLS-and-client-cert schemes do the job well enough most of the time.

Re:GSSAPI (2, Interesting)

Just Some Guy (3352) | more than 9 years ago | (#13484486)

It's also been on my "I really must implement that" list for waaaay too long.

I finally got around to setting up a KDC for my domains. It's nice to run "kinit" once, and then have full access to every machine I'm supposed to have full access to. Implementing Kerberos for one service is massive overkill. Implementing it for IMAP, SMTP, LDAP, etc. at the same time is bliss.

The FreeBSD Handbook has a nice chapter [freebsd.org] on the subject. O'Reilly's "Kerberos: The Definitive Guide" is an excellent reference as well.

Did that say signed vs. unsigned integer bugs? (1)

suitepotato (863945) | more than 9 years ago | (#13483967)

Isn't that a subject covered somewhere around the fourth or fifth class for ANSI C? And it took this long?

My how time flies when you're too busy with the bigger picture... At least they actually got around to the bug hunting.

Re:Did that say signed vs. unsigned integer bugs? (1)

shani (1674) | more than 9 years ago | (#13484415)

Unfortunately due to bad language design, finding signed/unsigned problems is often a subtle problem in C.

Here [phrack.org] is a phrack article on the topic.

Personally, I think the OpenBSD folks are doing things the hard way, by using an insecure language as the foundation of their work. That's the problem with C - you have to remember everything you learned over years of programming, all the time, or you risk making a mistake that can not only cause crashes, but ultimately compromise your entire machine, if not your entire network.

But having said that, I do use OpenSSH and occasionally OpenNTPd (on machines with interfaces that go up and down a lot). :)

Worth the wait (0)

usageman (912573) | more than 9 years ago | (#13484049)

I have waited along time for the release of the new OpenSSH 4.2 . I hoped they fixed the bugs and added soem goodies to this edition anyone here picked up a copy yet? I just hope it is everything it was talked up to be.

Proactive? (2, Informative)

non-poster (529123) | more than 9 years ago | (#13484145)

proactive changes for signed vs. unsigned integer bugs
Proactive changes for existing bugs? If the bugs are already there, then "proactive" is not the right word to use. See webster.com for "reactive".

Upgrade? (1)

Compenguin (175952) | more than 9 years ago | (#13484410)

Is it recommended that I upgrade OpenSSH to 4.2 on my OpenBSD 3.7 system?
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?