[lug] Looking for best way to avoid scripting password
blug-mail at duboulder.com
Sun Apr 5 19:36:52 MDT 2009
Chip Atkinson wrote:
> Hi Dave.
> My *reasoning* (emphasized to distinguish from an actual reason) is that
> it's bad to have an sshd that allows root logins. However, that sshd
> listens on another port that is inaccessible due to iptables rules on the
> server itself as well as the firewall in the middle.
> The risk of having an inaccessile sshd that allows root logins seems like
> it may be lower than having the password in plain text on another machine.
> I installed scponly on the server but was unable to get it working. The
> available documentation was rather sparse and other than a config option I
> did not see much about using rsync with it.
Still seems like a complicated way to do it. If you really need root to
perform the backups, why not just have a root cron job on the target that
backs things up to an external usb disk in a known location. Create an account
named backupxfr that is in its own group and make sure it can't write to any
part of the system except its home dir (and maybe /tmp). After creating
<the archive>, the target's root backup process does:
chmod 740 <the archive>
chgrp backupxfr <the archive>
The remote machine uses a shared key with no passphrase to access the target using
the backupxfr account and rsyncs/whatever <the archive>. Only one sshd needed,
no root access required. This does use additional disk space, but its relatively
cheap and you have a second copy even if the network connection goes out.
You have to have a cron somwhere to do the backup either remote or local, so
its not more complicated to do it on the target.
> On Sat, 4 Apr 2009, David L. Anselmi wrote:
>> Chip Atkinson wrote:
>>> On the remote host, I start an sshd with a different sshd_config that
>>> allows root logins. This sshd listens on a different port that is not
>>> open on the firewall.
>>> The only problem is that I need to sudo /usr/sbin/sshd.
>> Could you have root run that at boot (via an /etc/init.d script) and
>> just leave it up?
>> Is it really useful to do something that convoluted in the first place?
>> If you don't use a password you need a key to ssh in and then root's
>> key, right? Vs. if you let root log in in the first place you only need
>> root's key. Both (private) keys are on the same system so a compromise
>> there is bad whether there are one key or two.
>> It seems like this is just a bit of indirection, so security through
>> obscurity. Or maybe I'm not comprehending yet.
>> I'll have to think about it some more. What risk is the second sshd
>> intended to mitigate? Does it? Is that risk real? Is there something
>> (port knocking pops into my head) that mitigates an actual, rather than
>> perceived, risk?
>> Sorry, I'm in a bad place to think at the moment.
>> Web Page: http://lug.boulder.co.us
>> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
>> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug
> Web Page: http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug
More information about the LUG