[SAGE] SSH commanding; was Monitoring NT systems using open or f ree tools? (fwd)

[der.hans]

moin, moin,

for a more convoluted way to use ssh.

ciao,

der.hans
-- 
#  https://www.LuftHans.com/    http://www.TOLISGroup.com/
#  Two roads diverged in a wood, and I --
#  I took the one less traveled by,
#  And that has made all the difference. -- Robert Frost
#  I, OTOH, prefer to just go stomping through the desert... - der.hans

---------- Forwarded message ----------
Date: Fri, 8 Nov 2002 13:20:50 -0800
From: John LLOYD <jal@mda.ca>
To: Sage Mailing List <sage-members@usenix.org>
Subject: [SAGE] SSH commanding;  was Monitoring NT systems using open or f
    ree tools?



> -----Original Message-----
> From: Benjamin Feen [mailto:benjy@feen.com]
> Sent: November 8, 2002 12:08 PM
> To: Sage Mailing List
> Subject: Re: [SAGE] Monitoring NT systems using open or free tools?
>
>
> On Sat, Nov 02, 2002 at 12:27:40PM -0700, Trever Miller wrote:
> > Is there something wrong with automated tools running over
> > passphrase-less ssh connections or similar encrypted
> channels brought up
> > automatically to remote-execute whatever needs doing?
>
> Ooh! Ooh! I just learned a cool thing!  I wanna share it with
> the class!
>
> You can make it so that sshing to a particular account using
> a particular
> key executes a predefined command.
>

Yes this works and your brain will hurt after you're done.

We did a remote automated backup this way.  The backup clients were on one
subnet and one of them had a tape drive (with a person changing tapes every
night).

So, plan "A" was to have the tape-ful client ssh to the others and have them
ssh back to tapeful and dump to the tape.  However this leaves an open
(passwordless) SSH key on your tapeful client.  Not so great sometimes, if
this client is not so trusted.

So, we used plan "B", with a manager that was on another subnet across a
firewall.

We could trust the manager, so it had the open SSH key and it was this key
that the (public part) was copied to the tapeful client and it's peers.

The scripts look like this:

 on manager:
  eval `ssh-agent`
  ssh-add -f key_id_with_no_passphrase

  ssh tapeful "backup_yourself_to_tape"
  ssh tapeless1 "backup_yourself_to_an_8bit_session_to_tapeful"
  ssh tapeless2  "backup_yourself_to_an_8bit_session_to_tapeful"

Now, the trick is using ssh-agent on manager to control your keys.  You can
enable authentication forwarding from manager to tapeful and tapeless1 and
tapeless2 so that the 3 of them have mutual trust, yet nothing can happen
between them unless manager asks for it because only manager has the keys
and can cause forwarding.

The config file on manager (.ssh/config) says

Host tapeful
  BatchMode yes
  ForwardAgent yes
  Hostname truehostname
  ClearAllForwardings yes

(and similarly on the other nodes).  To back up, the script on tapeful says
"ufsdump to tape" and the scripts on tapeless1 say

  ufsdump 0uf - /usr | /usr/local/bin/ssh tapeful dd bs=32k of=/dev/rmt/0

So, how can tapeless1 use ssh to tapeful?  For two reasons:  first, because
manager forwards it's own credentials to tapeless1 and allows tapeless1 to
forward them *again*.  And, second, tapeful has tapeless1 listed in the ssh
known hosts file.

All this took a while to think out but it does work.

-John