Secure Passwordless Logins with SSH Part 3

[InfoSec News <isn () c4i org>]

+------------------------------------------------------------------+
|  Linux Security: Tips, Tricks, and Hackery                       |
|  Published by Onsight, Inc.                                      |
|                                                                  |
|  09-January-2003                                                 |
|  http://www.hackinglinuxexposed.com/articles/20030109.html       |
+------------------------------------------------------------------+

This issue sponsored by Hacking Linux Exposed, Second Edition.

Hacking Linux Exposed, Second Edition is out in stores and online.
This new version of the best-selling first edition includes almost
200 new pages of hacking and cracking materials for Linux and
Unix-like systems.

Also, if you order online through our web page (via Amazon or Barnes
and Noble), we'll donate any commissions to the Electronic Frontier
Foundation. Due to a Slashdot review, we anticipate donating $200
from January alone. See our books page for more information.

--------------------------------------------------------------------

Secure Passwordless Logins with SSH Part 3
By Brian Hatch

Summary: How to create passwordless logins to allow remote
administration tasks securely with SSH - restricting possible actions
for SSH identities.

Setting up your accounts to allow identity-based authentication gives
you several new options to allow passwordless access to those
accounts. This week we'll see how well we can restrict the access
granted to these identities.

$HOME/.ssh/authorized_keys files, are where you stick the public keys
of identities you wish to allow. These files without any arguments
look something like this:

  user@server$ cat ~/.ssh/authorized_keys
  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA3nCnBRQR2x4Ak7I3gS62ASXGiC+5o
  sLmOX5yS894rjFdFEVKgiuhuU0W7NdE3Mymkm0oX3oZM1e7NNxDx/4/Cu/4fISP8o
  pwN4GG2wbubZARFyJpWNMcVe8ZdOdmrlXFYh49a18i++SScHnycmiL8AmEb06Obrh
  kc5iAyVnHAf08Lqk= user@client_machine

The above code listing is wrapped and indented for readability, but
in reality everything should be in one line. The only spaces occur
between ssh-rsa and the key (which begins with AAAAAB3N above), and
before the comment, user@client_machine. If you are using an SSH2 DSA
key, it will look similar, but have ssh-dsa instead of ssh-rsa.

SSH1 identities, however look slightly different, as seen here:

  user@server$ cat ~/.ssh/authorized_keys
  1024 35 118175573790683499614097477370143348554184947854197722520
  41836228683278279897504160922892652206780215894929989167407130782
  38841607878229644157746694554723410376922636437979652730247511201
  90228759786298122911260638958674184210284497057700389946655115171
  90400155609012033981180255475519919550519308405663149133021266378
  user@client_machine

Regardless which version you use, adding options will be done in the
same way, so we'll assume RSA identities for simplicity.

When set up in this manner, anyone who possesses the private keys
that go with these public keys can log in as you on the server with
no restrictions:

  # Log in interactively
  client$ ssh user@server -i $HOME/identity_test/id_rsa
  user@server$ hostname
  server
  user@server$ exit

  # Run a command remotely
  client$ ssh user@server -i $HOME/identity_test/id_rsa "echo Success!"
  Success!
  client$

We can add several options to this key on the server to restrict in
which ways it can be used. Options are put at the beginning of the
line, before the key starts, and are separated from the rest of the
line by whitespace. Here are some of the more useful options. For a
full list, see the sshd manual page.

no-port-forwarding no-X11-forwarding no-agent-forwarding
    These options disallow port forwarding (tunnelling side channels
    through the encrypted ssh connection using the -R and -L options
    from the client side)[1], X11 forwarding (allow X11 apps to be
    started on the server, but viewed on the client securely), and
    agent forwarding (the ability to have the ssh-agent available on
    your client be accessible on the server) respectively. If we're
    going to be restricting our clients from doing anything but those
    activities we dictate, we'll probably want to include all of
    these options.
   
no-pty
    Most remotely-run commands do not require a pty, but allowing one
    isn't the end of the world.
   
environment="VARIABLE=value"
    If you want to have a specific environment variable set when this
    key is used (for example to change $HOME, make a restrictive
    $PATH, etc) then you can add as many environment options as you
    need. This is helpful if you have a single account used by
    multiple people, all accessing it via SSH identities, to set up
    their $LOGNAME variables, for example. Though you're better off
    using separate accounts and proper file permissions.
   
from="list"
    The sshd server can globally limit which hosts can connect to
    this machine by using TCP Wrappers, but cannot act on a host-user
    level. Using the from option, you can allow a given identity to
    be used only from specific hosts. Hosts are separated by commas,
    may contain wildcards "*" and "?", or may disallow hosts that are
    prefixed with "!". As an example, you may have
   
      from="!enemy.my_isp.net,*.my_isp.net,home.example.com"
   
command="shell command"
    When a user connects with this identity, the command specified
    will be run, whether logging in interactively or with a remote
    command. The environment variable SSH_ORIGINAL_COMMAND will
    contain the original command supplied by the user, if any.

So lets set up an example from the ground up.

Say you wished to allow the user "backups" on the machine
beepbeep.my_net.net[2] to be able to copy the /etc/ directory of the
machine futzy so you have a backup of the system configuration, just
in case futzy goes belly up. To make sure we get all the files in /
etc, we'll want to log into futzy as root. Normally you would run the
following command:

  backups@beepbeep$ scp -pr root@futzy:/etc/ /path/to/etc_backup/

The scp program automatically calls ssh to perform the actual
connection, which runs scp on the other side with appropriate
arguments. So, in order for us to do this, we must first configure
our SSH keys.

Here are the steps you'd need to take to get it working without a
password so the backups user can do this all from cron, no password
required. I'll breeze over some steps that were already described in
detail in the previous articles.

Log into beepbeep as backups and create the key:

  backups@beepbeep$ cd
  backups@beepbeep$ mkdir keys
  backups@beepbeep$ cd keys
  backups@beepbeep$ ssh-keygen -t rsa -f futzy.scp.etc
  Generating public/private rsa key pair.
  Enter passphrase (empty for no passphrase): enter
  Enter same passphrase again: enter
  Your identification has been saved in futzy.scp.etc.
  Your public key has been saved in futzy.scp.etc.pub.

  backups@beepbeep$ ls
  futzy.scp.etc  futzy.scp.etc.pub

Now, copy the public key up to futzy. (You can use many other
methods.)

  backups@beepbeep$ scp futzy.scp.etc.pub root@futzy:/some/tmp/dir
  root@futzy's password: <type password>

Now, log into futzy as root. We'll edit the public key to prepend a
"from=" option so the key can only be used from beepbeep, and then
add this to our authorized_keys file:

  root@futzy# cd /root/.ssh

  root@futzy# cat /some/tmp/dir/futzy.scp.etc.pub
  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAqwRPEALGQbrhQQST9Obkj2OJrUsaRi1
  SYtJbkpn6TxWddze2F/lzfKimgzaEhSWKuh/v0onGHvNaYuXWENdEhSWKuh/v0...

  root@futzy# vi /some/tmp/dir/futzy.scp.etc.pub
    # put  from="beepbeep.my_net.net" at the beginning
    # of this line, and exit the editor.

  root@futzy# cat /some/tmp/dir/futzy.scp.etc.pub
  from="beepbeep.my_net.net" ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAqwRP
  EALGQbrhQQST9Obkj2OJrUsaRi1SYtJbkpn6TxWddze2F/lzfKimgzaEhSWKuh...

  root@futzy# cat /some/tmp/dir/futzy.scp.etc.pub >> authorized_keys

We now have set up the root account on futzy to allow this key to log
in without a password, but only from beepbeep.my_net.net. Currently,
any program can be run from beepbeep, so let's test it out:

  backups@beepbeep$ ssh -i futzy.scp.etc root@futzy \
                    'echo "Hi, I am " `hostname`; pwd'
  Hi, I am futzy
  /root

You can also verify that this key is rejected from other machines.[3]

  othermachine$ ssh -i futzy.scp.etc root@futsy 
  root@futzy's password:

Now let's set up the key to run a forced command, regardless of what
the user sends us. On the server, let's create a file called /root
/.ssh/show-original-command as follows:

  root@futzy# cat <<'EOM' > /root/.ssh/show-original-command
  #!/bin/sh

  echo "Original SSH command is '$SSH_ORIGINAL_COMMAND'";
  exit 0;
  EOM

  root@futzy# chmod u+x /root/.ssh/show-original-command

And then modify the authorized_keys file using your favourite editor
such that it runs this command. The new version of authorized_keys
should look like this:

  root@futzy# cat /some/tmp/dir/futzy.scp.etc.pub
  command="/root/.ssh/show-original-command",from="beepbeep.my_net.ne
  t" ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAqwRPEALGQbrhQQST9Obkj2O...

So now, let's connect from beepbeep exactly as we did before:

  backups@beepbeep$ ssh -i futzy.scp.etc root@futsy \
                    'echo "Hi, I am " `hostname`; pwd'
  Original command is 'echo "Hi, I am" `whoami`; pwd'

So, let's try running our scp command and see what happens:

  backups@beepbeep$ scp -i futzy.scp.etc -pr \
                     root@futzy:/etc/ /path/to/etc_backup/
  Original command is 'scp -r -p -f /etc/'

Aha! Note that the scp command on beepbeep ends up running a very
different looking command on futzy, in this case scp -r -p -f /etc/.
If you think about it, that makes sense. The remote end doesn't care
where we're locally storing the files. If you try to find the -f
option in the scp man page, it's not there -- it indicates to scp
that it is running on the server side of the connection, and isn't
invoked by the user directly.

Many programs that can operate over SSH, such as rsync, run commands
that look different on the server side. Our show-original-command
program comes in handy to help you figure out what actual command was
sent to the server process.

Of course, since our show-original-command program didn't run scp on
futzy, our scp failed. Instead we need to force an scp command to run
on the server. So, for our final modification to authorized_keys,
make it look like this:

  root@futzy# cat /some/tmp/dir/futzy.scp.etc.pub
  command="scp -r -p -f /etc/",from="beepbeep.my_net.net ssh-rsa AA
  AAB3NzaC1yc2EAAAABIwAAAIEAqwRPEALGQbrhQQST9Obkj2OJrUsaRi1SYt...

And, now to run it from beepbeep:

  backups@beepbeep$ scp -i futzy.scp.etc -pr \
                     root@futzy:/etc/ /path/to/etc_backup/
  adduser.conf    100% |***********************************|  1660       00:00
  sources.list    100% |***********************************|   949       00:00
  host.conf       100% |***********************************|    26       00:00
  issue           100% |***********************************|    25       00:00
  motd            100% |***********************************|   162       00:00
  nsswitch.conf   100% |***********************************|   465       00:00
  profile          52% |*****************                  |   377       00:00
  ...

Excellent! But wait - what have we forgotten? There were a few other
options that are useful to restrict other features available to SSH
connections. Ideally we should add those in too. Adding all the
restrictions we can muster, our final authorized_keys file will look
like this:

  root@futzy# cat /some/tmp/dir/futzy.scp.etc.pub
  no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,c
  ommand="scp -r -p -f /etc/",from="beepbeep.my_net.net ssh-rsa AA
  AAB3NzaC1yc2EAAAABIwAAAIEAqwRPEALGQbrhQQST9Obkj2OJrUsaRi1SYt...

Whew! Quite a mouthful.

So, what have we accomplished here?

  * Created an SSH identity on beepbeep.
  * Installed and restricted that identity on root's account on
    futzy, such that:
      + The identity can only be used from beepbeep.
      + The identity can only be used to allow scp of the /etc/
        directory.
      + The identity can't be used to set up port forwarding over the
        encrypted channel, or other SSH features.

Should the identity fall in the hands of a cracker, it is useless
from any system other that beepbeep. If he has access to beepbeep,
all he can do is snag the /etc directory from futzy. Of course, the
most likely way he got access to the key was by getting access to the
backups@beepbeep account, so this would have already been available.
However the key, even though it allows root access to futzy, cannot
provide the cracker any other roads onto that system.

Now the drawback of this system should become clear if you think
about the limitations: each identity can only cause one command to
run. This means if you want to be able to run several commands, for
example mirroring /etc, downloading some logs, and then restarting
Apache, you'd need to create separate keys with separate entries in
authorized_keys for each. This can become a management pain,
especially since the entries in authorized_keys are fairly long.

Next week[4] I'll introduce a program I've been using for a long time
that allows you to have multiple authorized programs on a
host-by-host basis using only one key. You still need to maintain a
list of acceptable commands, but you do not need to generate separate
keys for each.

Until then, you may want to read an article by William Stearns
(author of ssh-keyinstall and more) at [5] which has many fun SSH
tricks.

NOTES:

[1] If you do want to allow specific port forwarding, you can use the
permitopen option to specify host:port combinations that are allowed.

[2] Beepbeep is, of course, the sound a truck makes backing up. Nods
to all my NUMBAlum brethren...

[3] You'd need to copy the key to othermachine, of course.

[4] Really, I promise.

[5] http://www.opensourcedigest.com/modules.php?name=News&file=
article&sid=6

                            -------------                            
Brian Hatch is Chief Hacker at Onsight, Inc and author of Hacking
Linux Exposed and Building Linux VPNs. He's been using SSH to secure
his remote logins since Tatu posted the first version of the code -
even if the administrators of those machines refused to install it
for him. Brian can be reached at brian () hackinglinuxexposed com.

--------------------------------------------------------------------
This newsletter is distributed by Onsight, Inc.

The list is managed with MailMan (http://www.list.org). You can
subscribe, unsubscribe, or change your password by visiting
http://lists.onsight.com/ or by sending email to
linux_security-request () lists onsight com.

Archives of this and previous newsletters are available at
http://www.hackinglinuxexposed.com/articles/

--------------------------------------------------------------------

Copyright 2003, Brian Hatch.



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo () attrition org with 'unsubscribe isn'
in the BODY of the mail.