Chris's Wiki :: blog/sysadmin/SSHKeyGoodPractices Commentshttps://utcc.utoronto.ca/~cks/space/blog/sysadmin/SSHKeyGoodPractices?atomcommentsDWiki2016-02-02T20:57:59ZRecent comments in Chris's Wiki :: blog/sysadmin/SSHKeyGoodPractices.By Jean Paul Galea on /blog/sysadmin/SSHKeyGoodPracticestag:CSpace:blog/sysadmin/SSHKeyGoodPractices:5b0186b196ce0aadbdef00a1272cba5893a8eb22Jean Paul Galeahttps://www.github.com/jeanpaulgalea<div class="wikitext"><p>If you're worried about your private key (and you should be), I'd suggest using a YubiKey 4:</p>
<p><a href="https://www.yubico.com/products/yubikey-hardware/yubikey4/">https://www.yubico.com/products/yubikey-hardware/yubikey4/</a></p>
<p>Caveat: I work for Yubico.</p>
<p>It does require a little bit more configuration initially; creating a gpg key, writing it to the YubiKey and configuring gpg-agent.</p>
<p>Once done, it's friction less though, especially the nano version.</p>
</div>2016-02-02T20:57:59ZBy Perry Lorier on /blog/sysadmin/SSHKeyGoodPracticestag:CSpace:blog/sysadmin/SSHKeyGoodPractices:46a55f1b546069d8c1462612b4bfb32fde064b78Perry Lorierhttp://www.lorier.net/docs/ssh-ca<div class="wikitext"><p>I have recently been experimenting with SSH certificates. The general idea is that you build a CA key ( <code>ssh-keygen -f /etc/ssh/ca</code> ) and lock it away on a machine you trust as a CA. (I usually use the TPM on my laptop).</p>
<p>Then for every new machine that you generate a key on, you copy the public key to your CA machine, and run:</p>
<pre>
ssh-keygen -s /etc/ssh/ca \
-I "$(whoami)@$(hostname --fqdn) user key" \
-n "$(whoami)" \
-z "$(date +%s)" \
sshkey.pub
</pre>
<p>This generates a <code>sshkey-cert.pub</code> file, which ssh will present along with your public key to servers.</p>
<p>Then, instead of putting in the <code>.ssh/authorized_users</code> file a copy of the public key, you put:</p>
<pre>
echo "cert-authority,principals=$(whoami) $(cat /etc/ssh/ca.pub)" >>~/.ssh/authorized_keys
</pre>
<p>Now, any key that is signed by the CA, and that has the principal of <code>$(whoami</code>) can login. Thus you can easily rotate keys for individual hosts regularly — possibly even daily, and you don't have to remember all the locations that need to have the key updated. People can, unfortunately, still track you via the CA public key.</p>
<p>Of course, this has just turned the problem into managing the rotation of the CA, but that's a key that is much easier to protect.</p>
<p>There's lots of other stuff you can do here, I've documented much of it in <a href="http://www.lorier.net/docs/ssh-ca">http://www.lorier.net/docs/ssh-ca</a></p>
</div>2016-02-01T10:50:32ZBy Grant on /blog/sysadmin/SSHKeyGoodPracticestag:CSpace:blog/sysadmin/SSHKeyGoodPractices:e44d133e80a9c725ebbe6aa8712469d55c787d2dGranthttp://dotfiles.tnetconsulting.net/home.html<div class="wikitext"><p>I wonder if it would be possible to leverage ProxyCommand to dynamically load and unload keys from the ssh-agent. I.e.</p>
<pre>
Host *
ProxyCommand sshProxyWrapper.sh %h %p
</pre>
<p>Where the sshProxyWrapper.sh script does the following:</p>
<pre>
ssh-add ~/.ssh/keys/${1}
nc ${1} ${2}
ssh-add -d ~/.ssh/keys/${1}
</pre>
<p>This is all pseudo code. You may have some odd things to deal with, like the fact that you can't use STDOUT / STDERR to ask for the key pass phrase. So, you'd probably only want to do this in X where you can spawn a new window to ask for the pass phrase.</p>
<p>This would still expose keys loaded into the agent when agent forwarding is in use, but it would reduce the number of keys exposed.</p>
<p>You could also probably limit the length of time the key could be used down to a number of seconds (30 ~ 90?).</p>
<p>You might also be able to leverage the LocalCommand to unload the key from the ssh-agent -after- using it to successfully authentic, and re-add it with the -c option, thus requiring confirmation before it's used again (if using forwarding).</p>
<p>If you stop to think about it, there's quite a bit that can be done to limit key exposure. All of them require a good understanding of the work flow and deciding what you want to do where.</p>
</div>2016-01-31T05:50:20ZBy Chris Siebenmann on /blog/sysadmin/SSHKeyGoodPracticestag:CSpace:blog/sysadmin/SSHKeyGoodPractices:9155598c29c8eba619ea3fdb62a0cc22e3479e18Chris Siebenmann<div class="wikitext"><p>Kevin Lyda: <a href="http://www.undeadly.org/cgi?action=article&sid=20160114142733">CVE-2016-0777</a>
shows a large reason why you should have multiple SSH keys. There
are circumstances where the remote end can compromise a key or you
can lose a key, and when this happens you want that key to have as
little access as possible.</p>
<p>(Also, <a href="https://utcc.utoronto.ca/~cks/space/blog/tech/SshAndMitM">while I believe that SSH keypairs are immune from man in
the middle attacks</a> I don't know enough to be
absolutely sure of that. If there is a MITM attack possible here under
some circumstances, using the same public key for everything is a great
help for the attacker.)</p>
<p>mtk: There are at least two problems with ssh-agent forwarding. The
first is that it gives an attacker who has compromised your account on
the remote machine the ability to authenticate with all keys that your
ssh-agent holds, protected only by whatever confirmation requirements
you've put on some keys. The second is that it gives such an attacker a
direct path to ssh-agent which they can use to mount direct attacks on
ssh-agent itself. Ideally ssh-agent doesn't have any buffer overflow
vulnerabilities or the like, but then ideally ssh itself wouldn't have
had <a href="http://www.undeadly.org/cgi?action=article&sid=20160114142733">CVE-2016-0777</a> either.</p>
<p>(OpenSSH itself has no support for limiting what ssh-agent keys are
available remotely. Although <a href="https://utcc.utoronto.ca/~cks/space/blog/sysadmin/SshAgentFiltering">people have written programs for this</a>, they have some drawbacks because they have to work
outside OpenSSH. And they still retain the 'more or less direct access
to ssh-agent' issue.)</p>
</div>2016-01-30T21:46:41ZBy Aristotle Pagaltzis on /blog/sysadmin/SSHKeyGoodPracticestag:CSpace:blog/sysadmin/SSHKeyGoodPractices:7bc2d870ed7dfde76d2477ddd0b3d1f761bf28d4Aristotle Pagaltzishttp://plasmasturm.org/<div class="wikitext"><p>Kevin:</p>
<blockquote><p>The public key portion doesn't identify anything.</p>
</blockquote>
<p>Yes it does. It identifies you. It can be used to find out that the person who has GitHub account X also has the system account Y on machine Z. This is relevant in both privacy and opsec terms (e.g. that simple fact right there might be enough information to launch a social engineering attack).</p>
</div>2016-01-30T14:53:14ZBy mtk@acm.org on /blog/sysadmin/SSHKeyGoodPracticestag:CSpace:blog/sysadmin/SSHKeyGoodPractices:7efb53e51ec2858964416df4503582dd06549036mtk@acm.org<div class="wikitext"><p>what is the problem with ssh-agent forwarding?</p>
</div>2016-01-30T14:08:35ZBy Alex on /blog/sysadmin/SSHKeyGoodPracticestag:CSpace:blog/sysadmin/SSHKeyGoodPractices:0e6d741d956bccc3b5ff58bee64abadf00039e85Alex<div class="wikitext"><p>Also NIST just released their final guide about this:</p>
<pre>
http://nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.7966.pdf
</pre>
<p>And mwlucas presentation is well worth watching:</p>
<p><a href="https://m.youtube.com/watch?v=fnkG9_jy2qc">https://m.youtube.com/watch?v=fnkG9_jy2qc</a></p>
<pre>
-Alex
</pre>
</div>2016-01-30T12:32:58ZBy Kevin Lyda on /blog/sysadmin/SSHKeyGoodPracticestag:CSpace:blog/sysadmin/SSHKeyGoodPractices:aedab5666b3573c240c21ee2f69928a7fc059645Kevin Lydahttps://phrye.com/<div class="wikitext"><p>"""
There are some basic and essentially universal things to start with. Use multiple SSH keypairs, with at least different keypairs for different services; there is absolutely no reason that your Github keypair should be the keypair that you use for logging in places, and often you should have different keypairs for logging in to different places."
"""</p>
<p>Er, why? The site you're connecting to never sees your private key, just your public one. A keypair per device makes sense (I archive private keys in <a href="http://www.passwordstore.org/">pass</a>) since a device could become compromised. An ssh keypair identifies an account on a machine. But your public key is fine to be, well, <a href="https://github.com/siebenmann.keys">public</a>. The public key portion doesn't identify anything.</p>
<p>I do think it would be nice to have a central place to track all my <code>authorized_keys</code> files so if a device was compromised or I regenerated a device's keypair I could have some sort of script run off and update all those files. Though the problem then is that things like github and bitbucket don't use <code>authorized_keys</code> files so it's a little complicated.</p>
</div>2016-01-30T07:27:17Z