Centos – Using SSH Keys with Kerberos

centoskerberosputtyssh

So there's an issue that we've been having at our company causing me to pull my hair out for the past week:

We have hundreds of server boxes (a mix of CentOS6/7, if it matters) that need to quickly be SSHed into on a daily basis between a team. Everyone is using mRemoteNG or SuperPutty as the ability to save and organize connection info as well as tabbed connections are a must have. Presently everyone is sharing a single SSH key to log into all boxes. Obviously our current practice is a terrible idea, so what we'd like to do is give each user an individual account and key to be used across the boxes.

Looking around, it seemed that Kerberos is a perfect option for managing multiple users and handling authentication across a la
rge amount of servers. Unfortunately we seem to be having some issues in getting it to work the way we want. We were able to set up Kerberos to handle SSH connections for users with passwords, but when it came to disabling passwords and using SSH keys, we couldn't figure it out.

We looked into using Kerberos keytabs as well, howevever we could not get them to work via PuTTY or find a viable solution to save connection info and have tabbed connections with keytabs.

The main question here is: Can Kerberos be used to manage SSH users with SSH keys? If not, is there a build of PuTTY available that works with Kerberos keytabs, or an alternative that can organize and have tabbed connections? Thanks!

Best Answer

First off, a clarification. Kerberos and SSH Keys are two mutually exclusive authentication methods for SSH. You don't use Kerberos with SSH Keys. You use Kerberos instead of SSH Keys. Both allow for "passwordless" SSH logon. A bit of reading on the Kerberos protocol may be in order.

With Kerberos, you need to obtain a TGT that proves you are who you say you are before you try to connect to your endpoint. If you're on Windows joined to an Active Directory domain, you automatically get a Kerberos TGT for the Active Directory realm on login. But a lot of organizations don't bother configuring their Linux hosts to use the Active Directory Kerberos realm. If you do, life is much easier. If you don't, it means that Windows needs to be configured to know about your other Kerberos realm and how to request a ticket. It's also an extra step for your users because they'll need to abandon their AD TGT and request a TGT for your other realm.

You also have the option to use a trust between the Kerberos realms such that (for example) AD users can authenticate to resources in the other Kerberos realm.

A Kerberos keytab file is just a file representation of your Kerberos account password. So when requesting your initial TGT, you wouldn't need to enter your password if you had a valid keytab file. But this is also generally outside the scope of your SSH client.

Once you have a valid TGT, you need to make sure your SSH client is configured to use GSSAPI. PuTTY supports this out of the box and I'm sure most others do as well.

Assuming everything is configured properly, it should "just work". But there are a lot of configuration mishaps that can happen along the way. There are also a lot of third party products that can make things easier, but I will refrain from mentioning anything specific.

Related Solutions

Ssh – way to SSH / SCP to another server as a different user, via a script

"Corporate S(tupidity)" :-)

SSH / SCP generally lives with the realm of UNIX philosophy I think. It is very rare that the designers of Unix applications intentionally make it so the administrator can't easily do something stupid. There will be generally be a warning like: "You probably don't want to do this because ... but, if you really want to, fine!".

In the case of passing a password to ssh in a script, they intentionally make this difficult, because it just such a bad idea.

At this point, I wouldn't even bother with SSH. You really need to talk with the corporate security people and come up with a real solution for the scenario. If they don't want to use keys, ask them what you should do. If that doesn't work, tell your managers what they want can't be done due to corporate security restrictions. If the managers do insist that you do this, get it in writing, or it is your ass on the line

Ssh – How to automate SSH login with password

Don't use a password. Generate a passphrase-less SSH key and push it to your VM.

If you already have an SSH key, you can skip this step… Just hit Enter for the key and both passphrases:

$ ssh-keygen -t rsa -b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/id_rsa.pub.

Copy your keys to the target server:

$ ssh-copy-id id@server
id@server's password:

Now try logging into the machine, with ssh 'id@server', and check-in:

.ssh/authorized_keys

Note: If you don't have .ssh dir and authorized_keys file, you need to create it first

to make sure we haven’t added extra keys that you weren’t expecting.

Finally, check to log in…

$ ssh id@server

id@server:~$

You may also want to look into using ssh-agent if you want to try keeping your keys protected with a passphrase.

Best Answer

Related Solutions

Ssh – way to SSH / SCP to another server as a different user, via a script

Ssh – How to automate SSH login with password

Related Topic