4

My colleague and i both ssh onto our work's ubuntu server, as the same "deploy" user, using key login. In our rails app console we have software which records who made changes, but it can't distinguish between us: it just sees the deploy user. Is there a way we can distinguish between us? does the system record which key was used to log in? That could an example of the sort of thing i could hook into to work out which of us actually logged in.

Note that this isn't a security question: if we both had to do something slightly differently in order to make this work we would both do it.

The most obvious answer is "Don't both log in as the 'deploy' user", and that would indeed fix it. But we don't want to do that.

thanks, max

3 Answers 3

5

Note that you can specify options after each key in authorized_keys. Perhaps use the environment="NAME=value" option and set a common variable to different values for each key. This variable then can be used to set the bash prompt and used in scripts.

The following is the relevant part of man sshd:

AUTHORIZED_KEYS FILE FORMAT
     AuthorizedKeysFile specifies the files containing public keys for public
     key authentication; if none is specified, the default is
     ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2.  Each line of the
     file contains one key (empty lines and lines starting with a ‘#’ are
     ignored as comments).  Protocol 1 public keys consist of the following
     space-separated fields: options, bits, exponent, modulus, comment.  Pro‐
     tocol 2 public key consist of: options, keytype, base64-encoded key, com‐
     ment.  The options field is optional; its presence is determined by
     whether the line starts with a number or not (the options field never
     starts with a number).  The bits, exponent, modulus, and comment fields
     give the RSA key for protocol version 1; the comment field is not used
     for anything (but may be convenient for the user to identify the key).
     For protocol version 2 the keytype is “ecdsa-sha2-nistp256”,
     “ecdsa-sha2-nistp384”, “ecdsa-sha2-nistp521”, “ssh-dss” or “ssh-rsa”.

     Note that lines in this file are usually several hundred bytes long
     (because of the size of the public key encoding) up to a limit of 8 kilo‐
     bytes, which permits DSA keys up to 8 kilobits and RSA keys up to 16
     kilobits.  You don't want to type them in; instead, copy the
     identity.pub, id_dsa.pub, id_ecdsa.pub, or the id_rsa.pub file and edit
     it.

     sshd enforces a minimum RSA key modulus size for protocol 1 and protocol
     2 keys of 768 bits.

     The options (if present) consist of comma-separated option specifica‐
     tions.  No spaces are permitted, except within double quotes.  The fol‐
     lowing option specifications are supported (note that option keywords are
     case-insensitive):

     cert-authority
             Specifies that the listed key is a certification authority (CA)
             that is trusted to validate signed certificates for user authen‐
             tication.

             Certificates may encode access restrictions similar to these key
             options.  If both certificate restrictions and key options are
             present, the most restrictive union of the two is applied.

     command="command"
             Specifies that the command is executed whenever this key is used
             for authentication.  The command supplied by the user (if any) is
             ignored.  The command is run on a pty if the client requests a
             pty; otherwise it is run without a tty.  If an 8-bit clean chan‐
             nel is required, one must not request a pty or should specify
             no-pty.  A quote may be included in the command by quoting it
             with a backslash.  This option might be useful to restrict cer‐
             tain public keys to perform just a specific operation.  An exam‐
             ple might be a key that permits remote backups but nothing else.
             Note that the client may specify TCP and/or X11 forwarding unless
             they are explicitly prohibited.  The command originally supplied
             by the client is available in the SSH_ORIGINAL_COMMAND environ‐
             ment variable.  Note that this option applies to shell, command
             or subsystem execution.  Also note that this command may be
             superseded by either a sshd_config(5) ForceCommand directive or a
             command embedded in a certificate.

     environment="NAME=value"
             Specifies that the string is to be added to the environment when
             logging in using this key.  Environment variables set this way
             override other default environment values.  Multiple options of
             this type are permitted.  Environment processing is disabled by
             default and is controlled via the PermitUserEnvironment option.
             This option is automatically disabled if UseLogin is enabled.

     from="pattern-list"
             Specifies that in addition to public key authentication, either
             the canonical name of the remote host or its IP address must be
             present in the comma-separated list of patterns.  See PATTERNS in
             ssh_config(5) for more information on patterns.

             In addition to the wildcard matching that may be applied to host‐
             names or addresses, a from stanza may match IP addresses using
             CIDR address/masklen notation.

             The purpose of this option is to optionally increase security:
             public key authentication by itself does not trust the network or
             name servers or anything (but the key); however, if somebody
             somehow steals the key, the key permits an intruder to log in
             from anywhere in the world.  This additional option makes using a
             stolen key more difficult (name servers and/or routers would have
             to be compromised in addition to just the key).

     no-agent-forwarding
             Forbids authentication agent forwarding when this key is used for
             authentication.

     no-port-forwarding
             Forbids TCP forwarding when this key is used for authentication.
             Any port forward requests by the client will return an error.
             This might be used, e.g. in connection with the command option.

     no-pty  Prevents tty allocation (a request to allocate a pty will fail).

     no-user-rc
             Disables execution of ~/.ssh/rc.

     no-X11-forwarding
             Forbids X11 forwarding when this key is used for authentication.
             Any X11 forward requests by the client will return an error.

     permitopen="host:port"
             Limit local ``ssh -L'' port forwarding such that it may only con‐
             nect to the specified host and port.  IPv6 addresses can be spec‐
             ified by enclosing the address in square brackets.  Multiple
             permitopen options may be applied separated by commas.  No pat‐
             tern matching is performed on the specified hostnames, they must
             be literal domains or addresses.

     principals="principals"
             On a cert-authority line, specifies allowed principals for cer‐
             tificate authentication as a comma-separated list.  At least one
             name from the list must appear in the certificate's list of prin‐
             cipals for the certificate to be accepted.  This option is
             ignored for keys that are not marked as trusted certificate sign‐
             ers using the cert-authority option.

     tunnel="n"
             Force a tun(4) device on the server.  Without this option, the
             next available device will be used if the client requests a tun‐
             nel.

     An example authorized_keys file:

        # Comments allowed at start of line
        ssh-rsa AAAAB3Nza...LiPk== [email protected]
        from="*.sales.example.net,!pc.sales.example.net" ssh-rsa
        AAAAB2...19Q== [email protected]
        command="dump /home",no-pty,no-port-forwarding ssh-dss
        AAAAC3...51R== example.net
        permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-dss
        AAAAB5...21S==
        tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...==
        [email protected]
8
  • aha - yes. the key that i already have in authorized keys looks like this: ssh-rsa <long string of chars> max@max-thinkpad-linux. (max@max-thinkpad-linux is my local username and local computer name, respectively). Can i read max@max-thinkpad-linux out of the environment? if not, then I can add an extra name-value pair to mine and my colleague's entries in authorized keys - off to try that now! Feb 28, 2014 at 11:15
  • Ok - i can't get this to work so far. I added environment="RAILS_USER_ID=1182" to the end of my entry in .ssh/authorized_keys on the server. I then exited and connected again with ssh. I then did echo $RAILS_USER_ID and got nothing back. (I also tried adding it to my local rsa.pub key as well, no joy). Am i misunderstanding something? Feb 28, 2014 at 12:42
  • The options go before the key at the beginning of the line, not after at the end. See the examples.
    – Dan D.
    Feb 28, 2014 at 12:44
  • ah, i beg your pardon. thanks. Ok, i moved it to the start, and now i can't login: i get Permission denied (publickey,keyboard-interactive).. I edited my local id_rsa.pub file to be the same as the authorized_keys entry on the server: both are environment="RAILS_USER_ID=1182" ssh-rsa <long string of chars> max@max-thinkpad-linux. Do i need to do something else when i update my key entry like this? Feb 28, 2014 at 12:53
  • Btw, i kept another tab open on the server so i still have access even though i'm locked out in my test tab :) Feb 28, 2014 at 13:00
1

OpenSSH sets a few environment variables that you might be able to use, but only if the client IP address is useful to you. In particular, SSH_CLIENT is set to the IP address of the client system and the port numbers in use.

7
  • I'm not sure if that would work: we both connect from our office, so would have the same ip as far as the server is concerned. AFAIK ssh always uses port 22 doesn't it? Feb 28, 2014 at 10:41
  • Actually, do you know what the second number in SSH_CLIENT is? I get eg <ip address> 35568 22 - what's the 35568? Feb 28, 2014 at 10:44
  • Ah, fair enough. ssh does use port 22 by default, but SSH_CLIENT also contains the ephemeral port number on the other end. Not that it helps you, sadly!
    – Flup
    Feb 28, 2014 at 10:44
  • ah - i think we just posted at the same time :) is the second number the "ephemeral port number" then? Feb 28, 2014 at 10:45
  • Yes -- it's a number allocated by the client OS which the ssh process binds to. This is how the OS knows which process to route the reply packets back to.
    – Flup
    Feb 28, 2014 at 10:46
1

Are you aware of the opportunities which sudo provides? Is sudo cool enough to convince you to not use the same account? With the sudo log you could record exactly what each other is doing.

You could each connect with your own user accounts and then use sudo -u deploy /yoursoftware/command param1 param2

Then in your sudo log you would have something like

Feb 28 xy:22:47 yourHost sudo:   MaxWilliams: TTY=pts/0 ; PWD=/mount/yourCWD ; USER=deploy; COMMAND=/yourSoftware/command param1 param2

I would imagine, you could set this up to run using key login. I assume you are running a command remotely and not actually logging in as user deploy. If so, then you would need to expand on this answer.

2
  • Hi - we are both connecting as the deploy user, with ssh deploy@hostname. Feb 28, 2014 at 11:16
  • @Max Williams I understand. However, you are asking sshd to do the work for which sudo has been developed. Although Dan D. seems to have found a trick for sshd to do what you want. Feb 28, 2014 at 11:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .