Changes between Initial Version and Version 1 of SSH

Timestamp:

03/29/11 16:33:28 (14 years ago)

Author:

Dave Morris

Comment:

--

SSH

@@ +1 @@
+== SSH keys and user accounts
+
+Public ssh keys for our team are stored on our data site
+
+    http://data.briccs.org.uk/sshkeys/
+
+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.