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

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.

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

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