Thanks. I'm familiar with ssh tunnels, pubkey authentication, ssh agents, etc. I use that quite a bit in other applications.
The issue I'm faced with is starting up a new listener out there in the DMZ. Any listener(even one only listening on the local adapter). That brings other people into this, with the associated reviews, paperwork, and so on. Reviews that I 100% agree with - putting on my security hat. I have a working and approved solution now using only socks/ssh and my custom scripts (from back in the Big Brother days when I first wrote this). I'm just investigating if it's possible to pull the formal Hobbit client into my existing solution methodology. Adding a listener is not a total deal breaker, I could probably gain the required approvals, but the overhead in getting that paperwork and approval done has me researching other possibilities.
Thanks for your detailed reply. Your solution is very much what I would have recommended to others in similar circumstances. I know from experience that it can be done simply and relatively securely. I think ssh is my favorite application. You can do so much with it. Tunneling, dynamic port forwarding, sshfs (a really cool technique to mount remote computers as local filesystems, with no server software required other than an ssh server).
-----Original Message----- From: Hobbit User [mailto:hobbit at epperson.homelinux.net] Sent: Sunday, June 03, 2007 8:34 AM To: hobbit at hswn.dk Subject: Re: [hobbit] Alternate to msgcache/hobbitfetch?
On Sat, June 2, 2007 22:50, Haertig, David F (Dave) wrote:
I guess what I'm looking for is a hobbitfetch variant that uses ssh/scp rather than connecting to a msgcache listener. And along with
that, a way to configure the client to collect data normally, but skip
starting a listening service.
Why not just use msgcache bound to a localhost address and ssh port tunneling, front-ended by autossh for persistence?
AUTOSSH_GATETIME=0 autossh -M 0 -f -f -N -L 127.0.0.2:1984:127.0.0.2:1984 \ -i <path-to-rsa-private-key> someunprivilegeduser at dmzserver.example.com
Install autossh. Do your key exchange, test ssh PKI authentication. Set msgcache to --listen=127.0.0.2 and --server=127.0.0.1, use "dmzserver.example.com 127.0.0.2 # testip pulldata" in bb-hosts, and you should be good to go, with a msgcache that cannot be fetched except via your tunnel. Note that the conn check for this bb-host entry will be meaningless, and you'll need to add -L port mappings for any other server-side tests you want.
Writing this from memory, so there might be a syntax error or misspelled option. But it's pretty close. You do need a very up-to-date ssh to specify the near-side IP on the -L port forward (which helps you to keep up with tunnels for different hosts--otherwise you have to use different ports; I actually put in /etc/hosts entries for the 127.0.0.x entries so I can call them by name). I know that the near-side ip spec is supported in the current repo versions for FC5 and up, RHEL5, and Centos5, but not in RHEL4 and down. Hope this helps.
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk