OpenSSH 4.2 released

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."

Comments

The new compression method is pretty fantastic.

[CyricZ]

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.

[nurb432]

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

Re:The new compression method is pretty fantastic.

[dmiller]

Sorry, but this new "method" (i.e. protocol method) not a new algorithm. In fact it uses zlib just like the standard one, but it delays its use until *after* the user has authenticated.

This way we avoid pre-auth exposure to zlib bugs.

Increased default key size.

[CyricZ]

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.

[Kjella]

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.

[h4rm0ny]

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.

Longer passwords on UnixWare?

[CyricZ]

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?

[dmiller]

Because nobody has ever asked or contributed code to make it work - this code was actally contributed by SCO themselves. We developers don't have access to ever system that OpenSSH runs on.

Speaking of X11-related improvements...

[CyricZ]

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.

But they didn't add new compression

[BobPaul]

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:Why you shouldn't use OpenSSH

[CyricZ]

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.

From Bill Gates...

[Anonymous Coward]

I'll take that, thanks!

Keep up the good work guys.

Re:Please excuse my obvious ass-kissing

[ScriptedReplay]

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:Why you shouldn't use OpenSSH

[slavemowgli]

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?

[Yaa 101]

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:It's our pleasure, Mr. Gates.

[ArbitraryConstant]

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:Why you shouldn't use OpenSSH

[ArbitraryConstant]

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:Still no logging of sftp/scp transfers?

[incubuz1980]

http://sftplogging.sourceforge.net/

Don't know if i works against OpenSSH 4.2.

But it probably will soon.

Slowing down dictionary attacks

[RAMMS EIN]

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 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

[RAMMS EIN]

``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

[jsveiga]

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

[crawly]

I personally use the following to limit the number of connection attempts on my SSH server. The limit is set for only 3-connections in a minute, the first 2 exhaust the limit-burst, which then takes a minute to refill, effectively limiting the connection attempt rate to 1/minute.

iptables -A INPUT -p tcp --dport ssh -m limit --limit 3/minute --limit-burst 2 -j ACCEPT

Re:Slowing down dictionary attacks

[accessdeniednsp]

Bah, I should clarify (sorry for not doing this first and sounding like an ass):

By accepting only non-syn packets, you are opening yourself up to "ACK" attacks and old-school router-penetrating scans. Also, things like 'ippacket' can forge packets by setting arbitrary bits. If the 'ack' flag is set (or in the case of your rule, anything including RST, PSH, URG, and even the two reserved bits), then the packet will zing right through your rule.

In this instance, the packet will pass thru the firewall, on to the destination host, which will then reply accordingly:

* If the port is not open, it will reply with ICMP Port Unreach (Type 3, Code 3) signifying a host is alive.

* If the port is open and these flags don't make sense to the host (invalid ACK window, or a FIN/ACK received without a FIN, or an ACK without a SYN, etc) then the host will reply with RST for that port. Implying the host is alive and that port is open.

These responses will only lead to further probes, etc.

For those who preach NAT until the cows come home, this will still happen because your firewall is still gonna un-NAT it and send it onward.

NAT will offer no protection in this situation. (and please do remember that the entire intar-web-net doesn't run on NAT. NAT is not a magical security tool and offers very little advantage with a magnatude of disadvantages, especially for high-load servers)

The state table checks, first, to see if the packet parameters match what has already transpired, session-wise. You can adjust the state timeouts to decrease or increase the time a session will remain 'open'. Now if the sessions are closed, it's removed from the state table period. No reply attacks, etc. The classic "Mitnick" attack will be avoided, too.

The state has expectations of how the packets flowing through should be handled. If you put the "-m state" checks very early in your ruleset, watch it with "watch iptables -L INPUT -nv" and then watch with 'iptstate' in another window. You'll see the first packet of a session (the initial SYN) will go thru the ruleset and be placed in the state table (upon being accepted of course)

EVERY packet from now until the final FIN/FIN-ACK will be matched against the state table in memory. The rule you are watching will only have ONE hit (for that session) even if you're transferring billions of bytes. The remainder is checked against the state table. It's very very cool and very very efficient and quite fast.

Anyhoo.. just wanted to clarify *why* you shouldn't use the ! --syn parameter.

Re:Please excuse my obvious ass-kissing

[Kynde]

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)

GSSAPI

[Craig Ringer]

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:-d option for scp?

[Jerf]

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".

Simple hack: sleep(10)

[HermanAB]

I simply added a sleep(10); to the file auth-passwd.c and recompiled.

int
auth_password(Authctxt *authctxt, const char *password)
{
        struct passwd * pw = authctxt->pw;
        int result, ok = authctxt->valid;
#if defined(USE_SHADOW) && defined(HAS_SHADOW_EXPIRE)
        static int expire_checked = 0;
#endif /* Password authentication delay */
                sleep(10);

That slows all password authentication attempts down enormously. ./configure --prefix=/usr --sysconfdir=/etc/ssh
make
make install
service sshd restart

La Voila!

Mod this nonsense down, its all wrong.

[Some Random Username]

1024 bit asymmetric keys for ciphers that rely on the assumed difficulty of factorization are about as difficult to break as 80 bit symmetric keys. And there is no reason to think it will stay that way, people continue to work on finding newer, more effectient methods of factorization.

Everyone knows a better algorithm than brute force: General Number Field Sieve, Number Field Sieve, Quadratic Sieve, and its likely new methods will be found. You don't brute force assymetric keys, brute forcing 1024 bit keys asymmetric keys would take just as long as brute forcing 1024 bit symmetric keys, that is to say it is not possible. Brute force means simply trying every possibility, the algorithm doesn't matter in that case. Trying 2^1024 possibilities is trying 2^1024 possibilities, regardless of how the key was generated or what its used for.

And finally, 1024 bit keys could certainly be broken without all the power of the sun, you are talking out of your ass, plain and simple. In fact, Bruce Schneier always says its likely that a billion dollars would be enough to put together the hardware required to break a 1024 bit key.

Re:Why you shouldn't use OpenSSH

[muonzoo]

Honestly, I've known Theo for over 15 years. That's longer that almost everyone else who has an opinon here.

That said, Theo is outspoken, loud, somewhat obnoxious and sometimes very hard to deal with. None of that affects the quality of his work. It certainly affects the quality of interaction you might have with Theo, or the perception you might have around his projects.

I certainly would not conduct my personal affairs with the same aplomb as Theo, nor would I piss in my own Corn Flakes quite like Theo can. This aside, Theo is an intelligent, smart individual and those who choose to draw from him that which is valuable will recognize that his different viewpoints, although sometimes objectionable, are just that : different viewpoints.

Sometimes, in the realm of the übergeek, it is difficult to remember that the goal is to produce the best software possible for the consuption and use of others.

I would never, (I repeat: NEVER), conduct my social affairs in the same fashion as Theo, however, I would be a happy man to be able to hang my hat on the solid line of quality software that he and his cadre of loosely joined pieces have brought us all.

I have partied with de Raadt, I have climbed, caved and even swooned over the same ladies. None of this matters. In the end, love Theo or hate him, he has contributed much to the OSS world and much to the security realm.

I may not choose to give him a grant allocation or hire him for my firm, however, Theo is Theo and at least he holds a consistent standard for himself and those who contribute to the projects he administrates. For this we can all be thankful. Interity is an essential element of honor; if you do not agree with how Theo condicts his affaris; so be it, but I think Theo makes the effort to conduct his own affairs within his own code of honor. Even if this code is incompatible with my own (and it appears to be) I have to respect that.