6 ms·
OpenSSH 6.5 Released
- jaryd 13y agoThe 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.
- stormbrew 13y agoBoth 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.
- djmdjm 13y agoMore details on the hostname canonicalisation here: http://blog.djm.net.au/2014/01/hostname-canonicalisation-in-openssh.html http://blog.djm.net.au/2014/01/hostname-canonicalisation-in-...
- nodata 13y agoThe 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.
- newman314 13y agoI 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.
- stormbrew 13y agoThe 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.
- mcpherrinm 13y ago* 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.
- jethro_tell 13y agoWhat is a KDF? What is this doing in layman's terms?
- swordswinger12 13y agoKey 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.
- sneak 13y agoWhen 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.
- XorNot 13y agoOpenSSH-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.
- dmm 13y agoFrom 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 http://marc.info/?l=openssh-unix-dev&m=123483715829020&w=2
- jaryd 13y agohttp://www.psc.edu/index.php/hpn-ssh http://www.psc.edu/index.php/hpn-ssh (for the uninitiated)
- midas007 13y agoIs there a patch for 6.4p1/6.5p1 or does 6.1p1 work?
- sneak 13y agoI 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)?
- andreaso 13y agoWell, FreeBSD 9.0 merged those patches into its OpenSSH. Perhaps that was what was floating in the back of your mind?
- jevinskie 13y agoI like the ability to use a null-cipher too. Handy when doing file transfers to embedded devices with puny CPUs.
- mct 13y agoI'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?
- fefe 13y ago"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 https://en.wikipedia.org/wiki/ChaCha20 Also used in: https://tools.ietf.org/id/draft-agl-tls-chacha20poly1305-04.html https://tools.ietf.org/id/draft-agl-tls-chacha20poly1305-04....
- arnehormann 13y agoChaCha is a little faster and apparently a little more secure. Dig through http://www.ietf.org/mail-archive/web/tls/current/msg10843.html 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.html http://www.ietf.org/mail-archive/web/tls/current/msg10630.ht...
- ballard 13y agoBrew formula for mac https://gist.github.com/8266138 https://gist.github.com/8266138
- akerl_ 13y agoAwesome! Any chance the keychain patches can be applied against this?
- ballard 13y agoPorted care of Debian patches and apple open source: https://github.com/steakknife/openssh/tree/apple-osx-openssh-portable 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.
- ballard 13y agoAs 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 http://github.com/steakknife/openssh
- sneak 13y agoWonderful 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.
- papaf 13y agoI 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.
- willvarfar 13y agoHow 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 ;)
- icebraining 13y agoEven those who don't have such rigs can just rent them from, for example, Moxie Marlinspike's Cloud Cracker: https://www.cloudcracker.com/ https://www.cloudcracker.com/
- sneak 13y agoBold 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 http://en.wikipedia.org/wiki/NSA_Suite_B_Cryptography
- m0nastic 13y agoAside 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).
- zwp 13y agoJust 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;23651c2.1401 https://listserv.nodak.edu/cgi-bin/wa.exe?A2=NMBRTHRY;23651c...
- justincormack 13y agoit 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.
- cm3 13y agoMore 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.
- newman314 13y agoGiven that Ubuntu 14.04 is not released yet, it would be great to see this in a LTS release...