SSH keys and user accounts
Public ssh keys for our team are stored on our data site
These keys are used by the install scripts to create our user accounts and add our keys.
Posting our public keys on a public site does not in itself represetnt a security issue. If a black-hat were to use one of these keys, all they could do is grant one of us access to one of their servers, not the ther way round.
However, it does mean that write access to the server hosting the data site needs to be treated as a security issue.
If a black-hat managed to substitute one of their keys for one of ours, then they would be able to use that to gain access to our servers.
Making ssh easier to use
I have lots of logins accounts on lots of different machines.
Adding host specific settings for each machine to your local ssh client config makes it much easier to manage what identity to use for which machine.
Note - configuration on your local machine (desktop/laptop) is up to you, so consider this as "works for me" advice rather than a recomendation.
For each remote host, I add something like the following to my ssh client configuration.
vi ~/.ssh/config
Host briccs-1
HostName briccs-1.rcs.le.ac.uk
User dm241
IdentityFile ~/.ssh/dave.briccs.org.uk.key
Protocol 2
Compression yes
PasswordAuthentication no
ForwardAgent yes
The host alias means that I can login to briccs-1 with just the following:
ssh briccs-1
The local client settings are used to fill in the details of what user account to use (dm241), what ssh key to use (dave.briccs.org.uk.key)
You can still override all of the settings using command line options
ssh root@briccs-1
will ignore the user name in the config and login as root instead.
Using agent forwarding
The service install scripts need to get data from our svn repository using ssh. That means we need a way to authenticate the ssh call from the target machine to the svn repository.
[desktop]
|
\--- ssh ---> [target]
|
\- jbossinstall
|
\- svn checkout
|
\--- ssh ---> [svn repo]
On local desktop, the user will be logged in using their normal user account.
On the target machine, the user will need to be logged in as root in order to install system packages and create top level directories.
The call to the svn repository needs to be done using a shared 'briccs' account so that an install done by one of us can be updated by another.
[user@desktop]
|
\--- ssh ---> [root@target]
|
\- jbossinstall
|
\- svn checkout
|
\--- ssh ---> [briccs@svnrepo]
We could use password authentication on the svn repository, but that causes some problems.
- Everyone in the team will need to know the password for the shared account
- The password will get written down on post-it notes and wiki pages
- If we need to change the password, we need to notify everyone who needs to use that account
- Once someone is given the password, we can't revoke their access without changing it for everyone
- The install script will need to prompt for the password
- The scripts can't be run unattended
Using ssh agent forwarding solves some of this, by using ssh keys and a chain of agents to authenticate access to the svn repository.
[user@desktop]
|
+- ssh agent <------------------\
| |
\--- ssh ---> [root@target] |
| |
| |
+------- ssh agent <----------------\
| |
| |
\- jbossinstall |
| |
\- svn checkout |
| |
\--- ssh ---> [briccs@svnrepo]
In order for this to work, the users ssh key needs to be added to the list of keys accepted by the shared briccs@svnrepo account.
With that in place, when the install script on the target machine tries to access our svn repository via ssh, the authentication request is passed back down the chain of agents to the users local machine.
Problems with agent forwarding
There are issues with using ssh agent forwarding. The most well know attack is by subverting the agent running on the intermediate system.
If a black-hat gains root access to the target machine while the one of us is logged in then they can use the unix socket created by the ssh agent to authenticate themselves as us on another machine.
