Draft IETF Standard for SSH Key Management Released 35
A few months ago, Tatu Ylonen (creator of SSH 1.x) declared that lax key management was hazardous. Now there's work being done on a standard for automated key management. hypnosec sent in the news; quoting Parity News on the content of the draft: "It presents a process that would allow for moving of already issued keys to protected location, removal of unused keys, key rotation, providing rights of what can be done with the keys and establishing an approval process for issue of new keys."
There's a non-WG mailing list; the final version of the standard is expected in October.
Great news (Score:2)
ldap? (Score:2)
There is some ways to recompile ssh to lookup using ldap, but I really wish that it would be baked in. I would love to just put a list of authorized keys, which host and user they go to, like we can with sudo in ldap.
Re: (Score:1)
AuthorizedKeysCommand
Re: (Score:2)
http://www.ohjeah.net/2011/06/09/linux-ssh-pam-ldap-sssd-2008-r2-ad-deployment/ [ohjeah.net]
The SSSD is intended to provide several key feature enhancements to Fedora. The first and most visible will be the addition of offline caching for network credentials. Authentication through the SSSD will potentially allow LDAP, NIS, and FreeIPA services to provide an offline mode, to ease the use of centrally managing laptop users.
The LDAP features will also add support for connection pooling. All
Awkward format... (Score:4, Interesting)
Given the fact that this document is a 'best practices' sort of thing rather than actually defining some sort of protocol, I find the venue of an RFC (even TFS incorrectly marks this sort of thing as a 'standard) questionable.
If they were looking for a techncial solution to actually enforce some of what is prescribed, basically it's describing the precise sorts of things x509 has baked in. Expiration rules to force examination of things like need-to know or even continued employment. Keys having to be blessed by an organizational authority rather than empowering each indivdiual user. Certificate revocation.
Basically, ssh *should* have embraced x509 as a PKI standard. The biggest failing of x509 is the CA system lacking a facility to limit scope of particular CAs leading to implementations shipping with a default set of free-for-all CA certificates. So long as ssh infrastructure doesn't pre-ship with any CA certs until the target organization adds one, that one flaw is mitigated severely.
Re: (Score:2)
The biggest failing of x509 is the CA system lacking a facility to limit scope of particular CAs leading to implementations shipping with a default set of free-for-all CA certificates.
I think the single biggest failing is that it uses centralized CAs which means expensive certs, which means people don't use the encryption except for specialized uses.
Re: (Score:2)
I think the single biggest failing is that it uses centralized CAs which means expensive certs, which means people don't use the encryption except for specialized uses.
The RFC is heavily worded around organizational management of keys. In that context, you aren't using Verisign or Thawte (and ideally you wouldn't even trust external CAs though certain frameworks like Microsoft's make that a challenging proposition), you are using one specific to your organization.
Re: (Score:2)
ASN.1 really does seem to be designed to be as close to impossible to implement as possible without actually getting it ignored entirely.
Re: (Score:2)
Given the fact that this document is a 'best practices' sort of thing rather than actually defining some sort of protocol, I find the venue of an RFC (even TFS incorrectly marks this sort of thing as a 'standard) questionable.
The use of RFCs as ways of managing best practices not only has a long and honourable history but is codified in a series of RFCs specifically marked "BCP" (Best current practice). Check it out yourself at RFC-Editor.org
Finnish name correction (Score:3, Informative)
Tatu Ylonen (creator of SSH 1.x)
Ylönen.
Re: (Score:2)
Tatu Ylonen (creator of SSH 1.x)
Ylönen.
Tell that to Giovanni Caboto|Jean Cabot|John Cabot. "A rose by any other name ..." That, and many, many other characters don't exist on my keyboard, and though I've heard there are ways to produce it it'd be used so seldom it's not worth the effort. Sorry Tatu, but thanks.
Re: (Score:2)
That's acceptable in some languages, but not Finnish.
This page [wikipedia.org] on Wikipedia explains.
Re: (Score:2)
Sorry, Slashdot ate the umlaut and turned it into a dash for some reason, so the link is broken. Type your own o-umlaut (alt-u, o on OS X, alt-0214 on Windows with the numeric keypad, *wave hands* on other systems).
Re: (Score:1)
In Finnish there is no tradition of replacing "Ã" with "oe" and it looks very odd. If it is too hard to write YlÃnen, I would prefer Ylonen over Yloenen.
In most cases you are able to understand/guess the Finnish words correctly even if you write "a" instead of "Ã" or "o" instead of "Ã" -- especially if they are in a sentence that has many words giving more context. However, there are (possibly dangerous) exceptions, like "ala" (= begin/start) and "ÃlÃ" (= don't).
Rare mention of commercial product in an RFC (Score:2)
In section 2.1 there's a rare shout-out to a specific commercial product in the body of the RFC. I guess it pays to author the RFC!
Maybe they should look at FreeIPA & SSSD (Score:2)
Why reinvent the wheel :-%
https://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/user-keys.html [fedoraproject.org]
5.3. Managing Public SSH Keys for Users
OpenSSH uses public-private key pairs to authenticate users. A user attempts to access some network resource and presents its key pair. The first time the user authenticates, the administrator on the target machine has to approve the request manually. The machine then stores the user's public key in an authorized_keys file. Any time that the user attempts to access
Re: (Score:2)
>> Which keys aren't user-specific?
Here's two general use cases I've seen:
When you're using keys to authenticate from automated systems, there often isn't a well-defined user, especially if the system has been designed to dump data from multiple pre-configured endpoints. (In this case every endpoint shares a client key for the length of the deployment.)
People authenticating to multiple systems start to use the same key on multiple systems. (This isn't bad by itself - it's similar to how client certs
Re: (Score:2)
Cluebats welcome.
I'm wondering what's wrong with "scp -rp ~/.ssh user@host:~/" (assuming pword auth can be enabled momentarily).
Re: (Score:2)
I'm wondering what's wrong with "scp -rp ~/.ssh user@host:~/" (assuming pword auth can be enabled momentarily).
ssh-copy-id [die.net] is what's wrong with scp. Your "solution" also copies your private key to the remote host, which is almost certainly undesired behavior.
Beyond that, your "solution" doesn't address the other issues mentioned in TFA, such as key rotation, key removal, centralized key administration, etc.
Re: (Score:2)
Cluebats welcome.
I'm wondering what's wrong with "scp -rp ~/.ssh user@host:~/" (assuming pword auth can be enabled momentarily).
1)PasswordAuthentication no
(One of the reasons to use keys is to avoid password cracking, and/or enforce two-factor/multi-factor authentication/authorizaion in conjunction with sudo or a VPN or similar)
2)AuthorizedKeysFile /etc/ssh/keys/%u.pub
(Many security frameworks don't allow non-administrative users to have full control over keys, as this can lead to abuse, such as a member of the dba group, who can run certain commands as the oracle user with auditing, giving him/herself unrestricted/unaudited access
Re: (Score:2)
On Fedora, the System Security Services Daemon (SSSD) can be configured to cache and retrieve user SSH keys so that applications and services only have to look in one location for user keys.
Huh? The only "applications and services" that have a reason to be interested in my public keys are OpenSSH and malware. And OpenSSH already knows where to find its own keys. Yet another reason to stick with Debian, I guess ...
Re: (Score:2)
FreeIPA and SSSD are not required.
Just OpenSSH with either the LPK patch, or the AuthorizedKeysCommand patch, or OpenSSH 6.2 or later.
I have been using ssh keys in LDAP since 2004, with OpenLDAP. FreeIPA, and its dependency on 389/RHDS (specific, non-standard features of 389/RHDS have been built into IPA, whereas many other web interfaces for LDAP have solutions to the same problems which don't rely on proprietary RHDS features) is unnecessary.
RFC for shit-togetherness ? (Score:2)
If people are lazy or stupid or both, how does some buzzwordy document help this?
Internet Draft - not a Draft Standard (Score:2)
This is an Internet Draft. Internet Drafts are the working documents of the IETF - some become standards most don't.
The IETF allows anyone to publish an Internet Draft. This is an 'individual draft' - produced by an individual, and not an IETF working group. So it's a bit disingenuous to say that the "IETF Opens Draft Version of Updated SSH for Public Review" as the linked article does. (And as noted, in other comments, this document is more about operational best practice than changes to protocol standards