Chris's Wiki :: blog/sysadmin/SSHWithCAAuthenticationViews Commentshttps://utcc.utoronto.ca/~cks/space/blog/sysadmin/SSHWithCAAuthenticationViews?atomcommentsDWiki2016-02-14T00:58:19ZRecent comments in Chris's Wiki :: blog/sysadmin/SSHWithCAAuthenticationViews.By Chris Siebenmann on /blog/sysadmin/SSHWithCAAuthenticationViewstag:CSpace:blog/sysadmin/SSHWithCAAuthenticationViews:83b2fa20c1cca0dd4e010027343fef66dcb198caChris Siebenmann<div class="wikitext"><p>As Grant probably already knows, centrally signing people's SSH keys
doesn't force them to keep the keys encrypted. Setting low expiry times
on the keys does limit the damage if (or when) they get compromised,
but it'd be better to avoid compromise in the first place.</p>
<p>(It also doesn't stop people sharing keys with others, but it does limit
the damage since one shared key can only authenticate to a single remote
user. You can't have some common key that's shared and used for access
to multiple accounts.)</p>
<p>My feeling is that if people are abusing keys, the only solution that
really works is giving them keys they can't abuse. Today this means
giving them keys that are permanently embedded in authentication
devices, such as Yubikeys. Then the most they can do is pass the
physical devices around, which at least means only user at once.</p>
<p>I pretty much agree with you about SSH certificates for host keys.
I'd expect this to be especially true if you have a constant churn
of machines getting built and torn down again, because then a lot
of people are connecting to a lot of machines for the first time.</p>
</div>2016-02-14T00:58:19ZBy Grant on /blog/sysadmin/SSHWithCAAuthenticationViewstag:CSpace:blog/sysadmin/SSHWithCAAuthenticationViews:195b31418922a84cac970a5b79eab9cddb96046cGranthttp://dotfiles.tnetconsulting.net/home.html<div class="wikitext"><p>Hi Chris,</p>
<p>I don't want to out and out agree with your comment (for a number of reasons). However, I will concede that user authentication with ssh certificates is the lesser of th evils. That is, it's not perfect, but it's better than some alternatives.</p>
<p>For starters, I'm proposing trading classical ssh keys for ssh certificates, not using them in conjunction with each other.</p>
<p>I come from an environment where user ID management is problematic at best. Passwords are always a problem, so I'm not going to say anything else about them. Frequently users would create and install (multiple) additional ssh keys that failed to follow best practices. (I.e. no pass phrase on the private key, and / or sharing said keys with others.)</p>
<p>I think that ssh certificates are a windfall in this type of environment. I feel that you gain centralized control over what certificates can be used to authenticate users to systems. Further, you can better restrict how long the certificates are good for, and what the certificates can be used for.</p>
<p>This is why I think that ssh certificates are SO MUCH BETTER than traditional ssh keys (at least for this type of environment) that I will continue to consider them to be a good thing and continue to suggest them to receptive audiences.</p>
<p>I REALLY like the fact that ssh certificates avoid the initial key exchange problem that so many people turn a blind eye to. (I've tried the DNS based SSHFP records, and they just don't work as well as I had hoped.)</p>
<p>Are ssh certificates the end all be all solution? No. Are ssh certificates better than many of the alternatives? Yes. Thus I consider ssh certificates to be the lesser of the evils.</p>
<p>...</p>
<p>So now you can worry about this less and go focus on your spam issue(s). ;-)</p>
</div>2016-02-13T20:00:28Z