OpenSSH 6.5 Released | Hacker News Reader

OpenSSH 6.5 Released

openssh.org

161 pointsmoonboots42 comments

The following two things are highlights for me:

  * ssh(1): Add a ssh_config(5) "Match" keyword that allows
   conditional configuration to be applied by matching on hostname,
   user and result of arbitrary commands.

 * ssh(1): Add support for client-side hostname canonicalisation
   using a set of DNS suffixes and rules in ssh_config(5). This
   allows unqualified names to be canonicalised to fully-qualified
   domain names to eliminate ambiguity when looking up keys in
   known_hosts or checking host certificate names.

Both great things. I'm pretty excited about elliptic curve keys and the ability to have ProxyCommand-like ProxyUseFDPass return an fd instead of act as an long-lived intermediary, personally.

A lot to like in this.

More details on the hostname canonicalisation here: http://blog.djm.net.au/2014/01/hostname-canonicalisation-in-...

The Match keyword is great, but the syntax of "and continue reading until the end of the file" is a pain. They should add an EndMatch keyboard to close the block, or force indentation or something.

I would still like to see an easy way to switch between a gateway ssh host and going direct depending on location/IP.

If I'm home, I want to be able to ssh to the gateway machine automatically and when I'm at work, go direct.

Obviously, this can be fixed with a shell script but it's hacky.

The Match keyword does allow you to configure based on your local address, so on first glance it would seem like it would allow you to do this, but for some reason ProxyCommand is not on the list of whitelisted keywords acceptable in a Match block. :/ That's really a shame.

Bold move, defaulting to Curve25519 ECDH.

I'm not saying DH/DLP is broken, but the NSA declines to include non-EC DH (or RSA, for that matter) in their Suite B of algorithms approved for internal applications. It's nice to have the option of ECDH for day to day use.

http://en.wikipedia.org/wiki/NSA_Suite_B_Cryptography

Aside from any security implications for EC, there's also a lot of practical benefits around the reduced sizes necessary.

We made a Suite B implementation for TPM's (where smaller key sizes are very very important).

Just for interest [I'm not saying it's broken either] but this is interesting DLP progress announced within the last 12 hours:

https://listserv.nodak.edu/cgi-bin/wa.exe?A2=NMBRTHRY;23651c...

* Add a new private key format that uses a bcrypt KDF to better protect keys at rest.

This is pretty important to me: Keys are much less of a hazard if taken off a stolen laptop/disk.

What is a KDF? What is this doing in layman's terms?

Key Derivation Function. It's a tool cryptographers use to derive cryptographic keys from different kinds of input material. Their most common use is to 'amplify' the entropy of a password or other low-entropy input and make it suitable for use as a key for a symmetric encryption scheme.

When you type in your password to decrypt your ssh private key on disk, it runs the string (and optionally also some salt, stored in the clear with the encrypted key to foil rainbowtable lookup attacks) through a key derivation function, or KDF. The output is used as the encryption key for the symmetric cipher that protects the key at rest.

One can use any cryptographically secure (output indistinguishable from random, infeasible to predict input given output, et c) hash as a KDF but the faster it is to run, the more per second an attacker can try when attempting to bruteforce your password/phrase after stealing your private key in its encrypted, on-disk format.

bcrypt is a function that is specifically designed to be somewhat time consuming to calculate (with a variable difficulty argument to the function itself), to reduce the bruteforce rate (in normal use, it's only run once or twice, once for each password input). Its cousin scrypt was specifically designed to also require a fair bit of memory to calculate, as well, reducing effective parallelism in fpga/asic implementations as the memory circuits must be included as well.

The difference between one <1ms hash and 100ms hash doesn't much matter to a user, but is the difference between a 10-char password being feasibly bruteforceable or not on dedicated hardware where you have to run 256^10 iterations. It adds up fast.

My ssh private key password is 8 chars that match [a-z0-9]. This matters a lot.

Ideally, a KDF should use as many resources as practical.

The NIST competition process of favoring performant algorithms is not always in the interests of users because it means it's cheaper to bruteforce/crack.

The NIST competition was for a hash function, not a key derivation function.

Err, more like 128^10 iterations, unless you have the unicode snowman in there.

yourmagicnoncrappypassword -> 101010101110101111...

Shouldn't your laptop/disks be fully encrypted anyways? It's good to have a strong KDF, but the stolen laptop threat should be already covered, I'd hope.

I have locks on my doors but that doesn't mean I don't have a pistol next to my bed.

True, but what if it's stolen while the laptop is turned on and the disk keys are in memory? I rarely shut my laptop off, and while I may be a little overly paranoid, it is certainly possible for a local attacker to gain memory bus access and read out disk encryption keys.

Multiple layers of security are always good!

Or use monkeysphere and gpg keys that serve as ssh keys, which (gpg priv keys) is itself encrypted on encrypted disks with passphrase in an 10M rounds of AES25 encrypted password manager with a very long passphrase itself.

OpenSSH-HPN's patchset really needs to be merged into the mainline. There's no excuse for not at least incorporating dynamic window scaling into the core protocol since it's such a ridiculous omission at this point.

http://www.psc.edu/index.php/hpn-ssh (for the uninitiated)

Is there a patch for 6.4p1/6.5p1 or does 6.1p1 work?

I was under the impression that it had been, though I don't know why i thought that.

You're totally right. Do we know why it hasn't been, yet (if indeed I am misremembering)?

Well, FreeBSD 9.0 merged those patches into its OpenSSH. Perhaps that was what was floating in the back of your mind?

From a quick look I didn't see any license associated with these patches.

Searching around on the -misc archives, djm claims performance improvements similar to HPN and declares no interest in implementing the NONE cipher(no encryption after authentication).

http://marc.info/?l=openssh-unix-dev&m=123483715829020&w=2

I like the ability to use a null-cipher too. Handy when doing file transfers to embedded devices with puny CPUs.

Wonderful to see them using a modern, time-hard KDF finally.

One wonders where the kickstarter to get a proper time- and memory- hard KDF patched into GnuPG is? It's not even really that much of a compatibility issue, either (unless you are sharing private key files between many machines)...

You'd really think the tinfoil-hat paranoids that (until Snowden) comprise(d) the bulk of the pgp userbase would care about the keys used to keep their log-term keys on disk private. I was flabbergasted to see the (relatively) tiny number of iterations in use in the GnuPG kdf.

I forgot my PGP passphrase and can no longer sign Java packages in the Sonatype maven repository. This is not a big deal for me but I did try to recover my passphrase.

I got an extension to John the Ripper that supports Gnu PGP keys and built a dictionary of permutations of words that I think I could have used in the passphrase.

I got nowhere. In this case, a passphrase > 20 characters was unbreakable to someone with modest computing power and an appropriate dictionary.

Edit: I did not save a revoke certificate because the Sonatype instructions did not include this step.

How far you get as a private effort is not really characterizing the threat; the threat is a determined attacker with AMD GPUs by the dozen. And while it is easy to discount state-sized efforts as being uninterested in signing your Java packages, the real threat are the hobbyists and criminally minded pros who really do have rigs and really do brag about how they do go attack the long lists of hashed passwords that often turn up after website breaches.

Please use bcrypt on your new key, the one you will be writing down the password to ;)

Even those who don't have such rigs can just rent them from, for example, Moxie Marlinspike's Cloud Cracker: https://www.cloudcracker.com/

More than a few people requested Github and Bitbucket to support more than RSA keys but they've both ignored the request for ECDSA for the last few years. The changes in 6.5 should inspire them to skip ECDSA and add Ed25519 as an option. Please Github and Bitbucket do everyone a favor and support modern keys. Next step is to save cpu cycles by using Curve25519 when available in the client. It's illogical not to.

I'm very happy to see djb's crypto work being supported in openssh!

Does anyone know offhand why ChaCha was chosen instead of XSalsa20, which is used in NaCl?

"ChaCha" family of ciphers aim to increase the diffusion per round while achieving the same or slightly better performance.The Aumasson et al. paper also attacks ChaCha, achieving one round less: ChaCha6 with complexity 2^140 and ChaCha7 with complexity 2^231

https://en.wikipedia.org/wiki/ChaCha20

Also used in:

https://tools.ietf.org/id/draft-agl-tls-chacha20poly1305-04....

ChaCha is a little faster and apparently a little more secure. Dig through http://www.ietf.org/mail-archive/web/tls/current/msg10843.ht... for reference.

EDIT found a better one: http://www.ietf.org/mail-archive/web/tls/current/msg10630.ht...

Brew formula for mac

https://gist.github.com/8266138

Awesome! Any chance the keychain patches can be applied against this?

Ported care of Debian patches and apple open source:

https://github.com/steakknife/openssh/tree/apple-osx-openssh...

Update: it doesn't build yet, minor patch issue will fix tomrw.

Update 2: Fixed building, no warranty.

I'll refactor into patches, will be much simpler to validate.

As an update, I've started with clean patches from sources so it's all in a git repo instead of spread out in brew files and gists.

http://github.com/steakknife/openssh

it also has:

* sshd(8): Add support for pre-authentication sandboxing using the Capsicum API introduced in FreeBSD 10.

Capsicum is a nice way to drop privs that shipped in FreeBSD 10 and is also being worked on for Linux.

Given that Ubuntu 14.04 is not released yet, it would be great to see this in a LTS release...

Reply on news.ycombinator.com