[NBLUG/talk] * password in /etc/shadow

Walter Hansen gandalf at sonic.net
Wed Jul 26 14:19:25 PDT 2006


> On Wed, Jul 26, 2006 at 12:27:25AM -0700, Walter Hansen wrote:
>> That's exactly what I want. The user is for backup purposes only. I'm
>> using rsync to download backup files to a local server (from a couple of
>> your servers actually). Passwordless login gives me the creeps unless
>> it's nessicary for scripting or another reason.
>
> Ah, then you might want to know about something else...
>
> In ~/.ssh/authorized_keys, you can put some stuff at the beginning of a
> line
> (before the stuff that would normally be there) to further lock things
> down.
>
> Here's an example:
> command="/usr/bin/rsync --server --sender -vlHogDtprS --partial .
> /some/dir/",from="127.0.0.1",no-pty,no-X11-forwarding,no-agent-forwarding,no-port-forwarding
> ssh-dss AAAA.... foo at example.com
>
> (pretend there's a lot more after the AAAA bit)
>
> This locks down that key to only running that command (do the rsync you
> want
> and look at what command it runs on the server, but use the full path to
> rsync), only coming from localhost (change IP to the one you actually want
> it to come from), and also restricts it from allocating a terminal,
> forwarding X, forwarding an ssh-agent connection or forwarding any ports.
> In other words, it can do only *one* single thing, making it much harder
> for
> somebody who breaks into the system you're running the rsync/ssh on to
> break
> into the system it's ssh'ing into.
>
> --
> Eric Eisenhart


Very cool. I'll have to look into this.

I'm not exactly sure what the comand that rsync executes when it logs on
via ssh. It would probably be recorded in history though. I'd imagine that
rsynic establishes the ssh connection, then runs rsync on the remote
machine with a specific command and then closes connection. Hmm. That
looks like what you've written. The action I"m using goes out to the
server that the download is on and grabs the download.

 I had put in from=xxx.xxx.xxx.xxx on one of the servers, but it didn't
work with the other (older os). I should probably try to upgrade ssh on
it, but I may run into conflicts. The server runs a critical process that
took a lot of fiddleing to get set up, so there's no interest in
upgrading/breaking it.






More information about the talk mailing list