
Using OpenSSH Certificate Authentication - p4bl0
http://neocri.me/documentation/using-ssh-certificate-authentication/
======
eik3_de
I stumbled across

 _> Logging in directly as root user is a bad idea — even in examples_

further down..

 _> ~/ssh_cert_authority/user_ca $ scp -rp user_ca.pub
root@example.host.net:/etc/ssh_

~~~
IgorPartola
You know what? Sometimes, it's fine. You should not share a root account with
other users. This advice comes from a time where you'd have the "root
password" and log into remote servers that way. Then, when someone leaves your
organization, you'd hopefully change the root password to make sure they
person that left no longer has access.

However, there are some concrete cases where logging in as root is just fine:

\- Making a database backup remotely. You have to give the backup user enough
privileges to initiate a database dump, stop the database process, grab the
backup, rotate the backups, start the database process up again. You can go
through the giant pain of setting up the permissions just so, or you can put a
separate SSH public key into /root/.ssh/authorized_keys and just let root do
all of this.

\- Initial VM setup. If you are automating something like provisioning EC2
instances, sure go ahead and set up individual users, but it's a lot easier to
first connect as root using your own keypair.

\- A remote monitor that logs into a single purpose VM to restart a process.
Same as the backups example, but more broad. Once again, you _could_ set it up
using specific users, but the system would be more brittle.

\- Lots of other cases where root is really what you want and doing sudo won't
work because the session is not interactive.

I figure it this way: if I compromised a local account on a server, I'd just
add `alias sudo=~/.bin/my-evil-sudo-that-emails-your-password` to your
.bashrc. That way I'd get root without any local exploits in the kernel, etc.
Basically, adding extra protection around the root account does nothing if you
are a sudoer.

Some steps you can take to actually increase your security instead of
following the advice that is so misunderstood:

\- Set the root password to a long random string, then lose the string. `su`
should never be used by anyone but root.

\- Disable password logins. Period. Do this now, and do it everywhere.

\- Disable password-based sudo. Use pam_ssh_agent_auth [1] to escalate
privileges and ssh-agent to forward your key through your ssh session. I am
not sure why this isn't the default, but it really ought to be.

\- Make sure your local key is encrypted with a strong passphrase. Once again,
use ssh-agent to not have to enter the password every single time.

\- Set up a VPN to access your servers and only allow ssh from the VPN.

\- For the truly paranoid, set up two-factor auth over SSH. This is easy to do
with Google Authenticator (it's just a random number with the seed being
shared and secret and the number being generated every 30 seconds), or using
SMS which is just slightly more complex/costly.

[1]
[http://pamsshagentauth.sourceforge.net/](http://pamsshagentauth.sourceforge.net/)

~~~
sn
I agree with everything except using ssh-agent to forward the key. The reason
is that if that one server is compromised, the root user can forward your
credentials to any other server that you have access to and if it is set up
the same way, also get root there. If you use password for sudo authentication
on that machine, they have your password but still don't have your credentials
to get into the other server. Reference: [http://unixwiz.net/techtips/ssh-
agent-forwarding.html](http://unixwiz.net/techtips/ssh-agent-forwarding.html)

~~~
IgorPartola
I believe it is possible to set up ssh-agent to ask you locally if you want to
respond to a challenge, listing the machine that requested it.

In either case, unless you use different passwords for every machine, ssh-
agent is already a net gain.

~~~
robryk
Unfortunately it doesn't list the machine that requested it. It's only
possible to tell what local process connected to the agent and login as what
username will be authenticated (the packet that the agent signs contains
essentially the username and hash of session secrets; notably absent is the
target hostname and target's public key fingerprint).

------
ehPReth
Is there a way to have it use a CRL instead of running around and ensuring a
certificate is marked as revoked on every device?

~~~
riskable
Unfortunately, no. It's the key reason why this feature isn't widely adopted I
think.

~~~
ehPReth
Ah, darn. Thanks for the reply

------
zobzu
similar, but using gpg, also interesting
[http://web.monkeysphere.info/getting-started-
ssh/](http://web.monkeysphere.info/getting-started-ssh/)

~~~
IgorPartola
This works really well with a couple of exceptions:

1\. It slows down your initial connection while it does another connection to
check the key

2\. You must convince everyone to use it, which is hard since gpg is hard.

I'd love to see more discussion of Monkeysphere on here. Every time I post
something about it it gets no votes.

------
stormbrew
This reminded me I wanted to investigate switching to this for our
infrastructure, but uh... it seems that on at least ubuntu's build of openssh
if you pass a serial number to ssh-keygen it segfaults. Even if it's the
default (0). That's kind of terrible.

~~~
voltagex_
Have you logged a bug report? I can't see anything that exists already from a
quick search.

~~~
stormbrew
Not yet, I will probably do so later though.

------
est
I secretly hope there's more adoption of client certs for browsers, bonus if
could share the same cert or openssh and browser.

------
jnazario
about time. this has been needed for a long time. ssh mitm attacks were too
easy, and legitimately changing server keys (which happens more often than you
would expect) would just confuse the issue.

so - about time.

tatu's decision to NOT use this feature of public key crypto when he designed
ssh keys has always been a point of frustration for me.

------
jamiesonbecker
Excellent article. I like the idea of running my own CA, but prefer the
Userify disconnected model instead.

