OpenSSH 4.2 released 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."
The new compression method is pretty fantastic. (Score:4, Informative)
Speaking of X11-related improvements... (Score:5, Informative)
- 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 (Score:5, Informative)
" 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:Please excuse my obvious ass-kissing (Score:5, Informative)
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.
Just use NX (Score:3, Informative)
Re:Still no logging of sftp/scp transfers? (Score:5, Informative)
http://sftplogging.sourceforge.net/ [sourceforge.net]
Don't know if i works against OpenSSH 4.2.
But it probably will soon.
Slowing down dictionary attacks (Score:5, Informative)
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.
GSSAPI (Score:5, Informative)
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? (Score:1, Informative)
Re:-d option for scp? (Score:5, Informative)
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: 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: 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:Increased default key size. (Score:5, Informative)
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:Slowing down dictionary attacks (Score:5, Informative)
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
Proactive? (Score:2, Informative)
Re:Slowing down dictionary attacks (Score:3, Informative)
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 (Score:3, Informative)
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).
HPN-SSH, faster network performance (Score:2, Informative)
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.
rsync is your friend (Score:3, Informative)
Then add '-H' to preserve hard links. (Why isn't -H part of -a? Oh well.)
RSA says that 1024 bit = 80 bit symmetric, not 128 (Score:1, Informative)
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?
Mod this nonsense down, its all wrong. (Score:5, Informative)
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:Slowing down dictionary attacks (Score:4, Informative)
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:The new compression method is pretty fantastic. (Score:4, Informative)
This way we avoid pre-auth exposure to zlib bugs.
Re:Longer passwords on UnixWare? (Score:4, Informative)
Re:Slowing down dictionary attacks (Score:2, Informative)
If you want replies for previously accepted requests, do NOT use ! --syn
Instead you should use the state table (which is what iptables was designed for).
iptables -A INPUT -j ACCEPT -s 0/0 -d (outer ip/net) -m state --state ESTABLISHED,RELATED
This is light years more efficient and secure. Also check out the iptstate [phildev.net] package so you can actually see what is in the magic state table.
Re:Slowing down dictionary attacks (Score:4, Informative)
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:The new compression method is pretty fantastic. (Score:3, Informative)