Alternatives to SSH x509 logon

Question

I have a Windows 7 machine which is not part of domain, and a Linux machine.

I want to login to Linux from Windows using an x509 certificate stored in windows certificate store.

Is it possible?

Quoting How to set up OpenSSH to use x509 PKI for authentication?

I do not mean simply putting the public RSA key of a x.509 certificate into ~/.ssh/authorized_keys - I'm looking for a way to set up a ssh such that x.509 certificates signed by a pre-defined CA will automatically be granted access to the linked user account. RFC 6187 seems to suggest such a functionality

I don't want to to install keys for each user instead of just CA certificate and a machine certificate and mapping certificate DN to host usernames to authorize.

From https://serverfault.com/questions/417518/windows-ca-to-issue-certificate-to-authenticate-ssh-to-a-linux-server?lq=1 it seems it is only possible with a forked OpenSSH server. Following an answer there

I'm not inclined to diverge from the main branch of OpenSSH myself, security is too important and I don't have the resources to properly verify this significant of a change

The patch is 200KB long, too easy to shoot yourself in the foot with such type unsafe language as C without a large community the main OpenSSH branch has. Moreover, it seems to implement an older draft instead of RFC 6187

OpenSSH community is not interested in x509 because it's a pain to work with such a large specification:

The developers have maintained a stance that the complexity of X.509 certificates introduces an unacceptable attack surface for sshd. Instead, they have [recently] implemented an alternative certificate format which is much simpler to parse and thus introduces less risk.

The above "alternative certificate format" is not a good idea to me either. X.509 is widely supported, so 2 certificates and 1 private key can serve in many different places, e.g. in TLS, IPSec, S/MIME and other applications of CMS. Moreover centralized revocation similar to CRLs is not supported so the revocation of "alternative certificates" with compromised private keys is tedious and error-prone.

So far the only viable option is GSSAPI - it is even supported by PuTTY.

Is there anything else to simplify SSH key management?

Answer 1

There's a set of patches for adding X.509 certificate support to OpenSSH maintained by Roumen Petrov. This allows you to use X.509 client certificates to authenticate SSH connections.

For example, you can something like this in ~/.ssh/authorized_keys:

# X.509 by DN
x509v3-sign-rsa DN /C=US/O=Example org/OU=Administrators/CN=David Coles

One downside is that you'll also need a similarly patched OpenSSH client to connect to these servers or a third-party SSH client that supports X.509 certificates (for example, SecureCRT). Additionally, very few Linux distributions carry these patches, so you'll probably have to apply the patches and build OpenSSH server yourself.

A slightly different approach that doesn't require modification to the client would be to use normal public-key authentication, but to use OpenSSH's AuthorizedKeysCommand configuration option to look up the SSH key in a centralized database (for example, from an LDAP attribute for that user).

Answer 2

I believe GSSAPI with a fallback to password is a good option.

The above "alternative certificate format" is not a good idea to me either. X.509 is widely supported, so 2 certificates and 1 private key can serve in many different places, e.g. in TLS, IPSec, S/MIME and other applications of CMS. Moreover centralized revocation similar to CRLs is not supported so the revocation of "alternative certificates" with compromised private keys is tedious and error-prone.

Yes, it is a very bad idea to reuse one private key in two different certificates. Actually, it is a bad idea to use one private key for different purposes/protocols period. Even though it is technically possible to use a single x509v3 certificate for TLS, IPSec, S/MIME, etc. at the same time, it is a cryptographic bad practice called key-reuse.