Slashdot Mirror
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."
"proactive".
I've found that it offers a good 10% to 15% decrease in data size compared to the previous method.
Cyric Zndovzny at your service.
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.
Cyric Zndovzny at your service.
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?
Cyric Zndovzny at your service.
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.
9/11: Never forget it was a false-flag operation
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.
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.
Cyric Zndovzny at your service.
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.
I'll take that, thanks!
Keep up the good work guys.
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.
Cyric Zndovzny at your service.
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.
Post is bollocks - "new" compression method is a security fix, not a functional improvement.
Sigh. Back to my commercial (vandyke vshelld) implementation....
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.
Cyric Zndovzny at your service.
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.
Léa Gris
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?
if you don't want to pay for the nomachine license, freenx is pretty decent.
The Raven
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.
Please correct me if I got my facts wrong.
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.
Scroogle
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.
..on any given day.
/var/log/messages|wc -l
:-)
Box #1:
grep "authentication failure"
/var/log/messages|wc -l
1362
Box #2:
grep "authentication failure"
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 (it is a wiki, so I can easily remove your work if you mind, or you can do it..)
9/11: Never forget it was a false-flag operation
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.
If my grammar and spelling are off, I am [distracted/tired/careless] (take your pick)
``I hope you do not mind I recycled them at http://en.linuxreviews.org/Ssh''
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!
Please correct me if I got my facts wrong.
Didn't know about DenyHosts, wrote something similar in sshd_failed_ips.pl. 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?)
Belief is the currency of delusion.
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.
Is it recommended that I upgrade OpenSSH to 4.2 on my OpenBSD 3.7 system?
http://www.psc.edu/networking/projects/hpn-ssh/
there is a patch called HPN-SSH that addresses some issues in ssh that users encounter if they have access to faster networks. SSH has some static flow control buffer values that limit network performance. The work at PSC by Chris Rapier and Michael Stevens is really nice, is proven to work and is gaining (some) broader acceptance.
take it for a test run and if you like it, please encourage the OpenSSH folks to add it into the main trunk.
Then add '-H' to preserve hard links. (Why isn't -H part of -a? Oh well.)
Why do you think 1024 bit asymmetric is roughly equivalent to 128 bit symmetric when numerous sources say it is closer to 80 bit symmetric?
0 4
Here's a quote from RSA Security:
"The design confirms that the traditional assumption that a 1024-bit RSA key provides comparable strength to an 80-bit symmetric key has been a reasonable one." -- http://www.rsasecurity.com/rsalabs/node.asp?id=20
And I don't believe any literature says 1024-bit DH key provides 128-bit symmetric key strength either. Where did you get your info?
I simply added a sleep(10); to the file auth-passwd.c and recompiled.
/* Password authentication delay */
./configure --prefix=/usr --sysconfdir=/etc/ssh
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
sleep(10);
That slows all password authentication attempts down enormously.
make
make install
service sshd restart
La Voila!
Oh well, what the hell...
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.
Out of his ass, as usual.. This is /.
Yup, that, perhaps combined with a certain natural reluctance to support a company whose main business seems to be litigation and FUD, rather than software, these days. Frankly, I'm a bit surprised that any Unixware enhancements were added at all. I suppose it's not the customers' fault that their vendor has turned into a rabid dog, but still....
There was a quote i heard once, it went something along the lines of this.
"He was a supremely arrogant man, but he carried it well, because he was usually right."
This wasnt made as a reference to Theo at the time, but it seemed apt
Just FYI, this is NOT a "Linux" tool. It's more of an OpenBSD thing than anything else, to be frank. It's just that it was made portable, ported to Linux, and other OS's... Not trying to be ignorant here, but this is just for your own understanding and others. Check it out when you can - www.openssh.org. Regards.
(anon to avoid karma whoring)
From the release notes:
"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."
Kerberos uses symmetric encryption. While unlike regular logins it doesn't sent password hashes across the network (just tokens encrypted with those hashes, that people who entered the right password can decrypt), it's still not secure in that it keeps credentials on the KDC. A compromise of the KDC therefore allows an attackers to pretend to be anyone they want.
No modern authentication system should store secrets on the server, This is the reason we have PKI - we store the certificates on the server, and each user is the only person who has their private key. This means:
- A compromise of the authentication server gives the attacker...public keys, that they could get from anywhere.
- It's more easy to hold a user responsible to accidential or deliberate disclosure of their credentials, because only the user has those credentials.
Kerberos was secure when it was invented, But there's no reason my bank needs to store my credentials on their servers, thank you very much, and there's no reason I feel like letting them be responsible for the security of my account any more than necessary. It's popular because of the single sign on aspect (users get an initial token at login time they can use to auth to NFS servers, mail servers, CVS/SVN servers, web servers, etc without needing to retype their password, at least till then login token expires). And lots of apps - every client/server for web, mail, CVS, SVN, NFS, etc in RHEL 4 for example, supports it. But ssh-agent is almost as convenient for SSO - I just wish more apps accepted digital signatures for logon.
So yeah, I can see why you'd use kerberos for network app support, but it's a poor second cousin to PKI when it comes to security.
A new version of my favorite Linux tool!
Hey the SSH server and client can work on Windows too! Install Cygwin to find out. I've been using Cygwin/SSH for about 6 months now and I love it. SSH into the machine, remote (secure) VNC, scp/sftp it's all there and was pretty simple to setup.
I love Cygwin more, because it gives me SSH, but without each other I wouldn't use either.
Get your Unix fortune now!
One of the major drawbacks of OpenSSH was the lack of a per-account/per-key based traffic-accounting. I always had the impression that the developer of OpenSSH opposed the basic idea of getting precise data about how much everyone did even if it still is possible for the admin to track everything from outside SSH.
"Life is short and in most cases it ends with death." Sir Sinclair
For end users, perhaps the best feature in this release is
- Added ControlMaster=auto/autoask options to support opportunistic
multiplexing (see the ssh_config(5) manpage for details).
'Multiplexing' means running more than one session across the same ssh connection. So if you use CVS over ssh, or rsync over ssh or even just lots of remote commands, you don't have to start up a new connection for each one. The first ssh connection stays running and new sessions are opened over it. This cuts down the initial network traffic a lot. Great news for modem users and a worthwhile improvement in responsiveness for everyone else.
You need to set up ControlMaster=auto in your ssh_config, which can be in your ~/.ssh/ directory.
-- Ed Avis ed@membled.com
Yes, this is correct. Kerberos is only as secure as your KDCs. The developers of Kerberos did not make a secret out of this, though. That said, Kerberos makes a lot of sense in some environments and not so much in others. You always have to choose the best tool for the job.