On Mon, Dec 15, 2008 at 10:55:56AM +0000, Brett Parker wrote:
On 15 Dec 01:30, Wayne Stallwood wrote:
On Sun, 2008-12-14 at 22:54 +0000, Chris G wrote:
Solved!
At first I thought it couldn't be done as a Google search turned up someone trying to do something similar and being told it wasn't possible using AllowUsers and DenyUsers, which is true, but there's a new[ish] directive which makes it possible.
The answer is to us a Match section at the end of /etc/ssh/sshd_config as follows:-
Match Address 192.168.1.7 PermitRootLogin without-passwordAs the body of /etc/ssh/sshd_config already has "PermitRootLogin no" this does exactly what I want, it's only possible to ssh to root from 192.168.1.7.
A handy tip and one I was not aware of..as per your initial search results my first instinct was to say it wasn't possible without running two instances of the ssh server on different ports.
However...I am assuming the one machine that needs root needs it for some specific purpose and that being the case would it not have been possible to meddle with sudoers so that a specific user other than root had permission to do whatever it was you need to do from that machine via a promptless sudo ?
Silly puppy, it's no more secure that way... and you can lock down what a non-interactive keybased ssh auth can do (check man sshd, then look for AUTHORIZED_KEYS FILE FORMAT). limiting the command to the backup set is probably better than using sudo, and gives less scope for people to abuse it than giving out sudo (you have to be very limiting to make it so that you can't break out in to a root shell with sudo ;)
That would strike me as the better practice because now with a key only based authentication between two boxes if 192.168.1.7 got compromised then it would have open root access to the other machine.
See above, you shouldn't need to do that if you limit the command set in the authorized_keys file.
I had originally implemented what I wanted by using 'from "xxx, yyy"' in the authorized_keys file but the Match way is a lot simpler and while maybe not quite so secure is good enough.