[clug] Automating SSH scripts with passphrase'd keys

[Michael Cohen]

Steve,
  The reason that the complexity is there is because you need to
manage this automated process. By definition if the process is
automated it means it needs to proceed automatically with no user
intervention. This means that by definition the scripts and the
systems participating in the process need to be intrinsically
authorized.

The problem is how to limit this authorization so that no system
inherently trusts other systems too much. You might find the
configuration complex - i find it much simpler because it answer the
question of who is authorized to do what more clearly. If you use
ssh-agent as previously proposed, to authorize a script its the same
as using unencrypted keys - because no one is there to actually unlock
the keys. The user which is running the scripts has full access to
those keys to do anything they wish.

By using forced commands (as in the example you gave) you are able to
limit exactly what it is that the script is able to do on the server.
This gives the remote system exactly the level of privilege it needs
and no more. Without forcing the command the remote system has
complete access to the system it ssh's into.  Since, by definition,
the login is automated, any process running on the system is able to
log into the backup server any time. This might be an acceptable risk
but generally is frowned upon (its the same as having un-encrypted
private keys - anyone using your user account can login to all systems
you are authorised to - this means compromise of one account on one
system automatically means all other systems are also compromised).

You dont need to write a subsystem for ssh to do simple tar commands -
if you follow the ssh command with a command string, that will be
executed on the remote system and your stdin will be connected to the
stdout of that command. For example something like this will deposite
the tar ball on the remote system:

tar -cz /home/ | ssh backup at remote_server dd of=/var/backups/home_dir.tgz

The forced command bit simple ensures that the only thing you can do
is deposite the file on the remote system.

Scp is not a proper ssh subsystem its simply a program which encodes
the files in a certain way and writes to stdout, and does the opposite
on the other end. The following commands are equivalent (this is an
approximation off the top of my head):

scp file remote_system:/tmp/

Is the same as:

scp -t file | ssh remote_system scp -f /tmp/

Michael.


On Mon, Mar 24, 2008 at 7:04 PM, steve jenkin <sjenkin at canb.auug.org.au> wrote:
> Michael Cohen wrote on 24/3/08 6:52 PM:
>
>  You can use 'rsync' with SSH as the transport. It's a pity that there
>  isn't an SSH sub-system like 'scp' for 'tar'.
>
>  A single  user can have many set of ssh keys, the .ssh/config file on
>  the originating system can have many aliases for access as one or more
>  users to a (backup) server.
>
>  In the home directory for the user on the backup server, in
>  ~/.ssh/authorised_keys, you can have a specific command (rsync or tar or
>  scp) associated with a key - no matter what the originator asks ssh to
>  run, only the specified command is run on the server.
>
>  I've seen this used extensively at one site - but I didn't like it :-(
>  Too many keys to maintain, and lots of complexity in the config files.
>
>  If you trust scripts (shell, perl, python) to be a wrapper, you can
>  implement your own sub-system - but it's nasty for my tastes.
>
>  good luck - like to hear what you decide to implement.
>
>
>  > Li-Jie,
>  >
>  >   Creating a special user on the server end is the best way to go -
>  > something along this for a forced command might be best: dd
>  > of=`date`.tar.gz
>  > and then on the desktop you would do a cron job which does:
>  >
>  > tar cz /home/ | ssh backup at server whatever
>  >
>  > for example. The "whatever" is any command it doesnt matter as it will
>  > be ignored anyway (the server will always run the forced command) but
>  > is needed to make ssh not try to bind a pty (i.e. so it knows its not
>  > an interactive shell).
>  >
>  > If someone was to compromise the desktop they could send the server
>  > tar files securely thats about it because they can not issue any other
>  > command on the server than the dd command. If you want to get more
>  > sophisticated you can write perl/python scripts to do anything based
>  > on lots of parameters obtained via the environment of the forced
>  > command like source ip, and even the command that the desktop wants to
>  > run (the "whatever" above). This btw is how scponly is implemented to
>  > allow scp services only to certain hosts, from ips, only upload no
>  > download and lots of other policies.
>  >
>  > Michael.
>  >
>  >
>
>
>  --
>  Steve Jenkin, Info Tech, Systems and Design Specialist.
>  0412 786 915 (+61 412 786 915)
>  PO Box 48, Kippax ACT 2615, AUSTRALIA
>
>  sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin
>
>  --
>
>
> linux mailing list
>  linux at lists.samba.org
>  https://lists.samba.org/mailman/listinfo/linux
>