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

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.

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:Increased default key size.

[Anonymous Coward]

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.

Compression algorithms do matter.

[CyricZ]

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:Please excuse my obvious ass-kissing

[thc69]

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:Slowing down dictionary attacks

[Anonymous Coward]

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:I get a truckload of dictionary attacks

[xiando]

..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:GSSAPI

[Just Some Guy]

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.

Re:Please excuse my obvious ass-kissing

[Anonymous Coward]

I call this idea "tool day" and try to have one every 3 months or so. Spend the day playing with your tools trying to do things you think you want them to do: get around annoyances, do things faster or cleaner, do new functions, etc., or just browse the docs or the web for cool ideas.

Recent things learned:

• screen: "stuff" to push characters into input queue
  
• zsh/ssh: tab completion for hostnames
  
• ssh: stop password retyping: ssh-agent use
  
• vim: look up word definitions with 'K': keywordprg=dict
  

I think the idea is independent of "OSS".

#toolday should be an IRC channel.

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!

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.