By default I have sshd set up to disallow root logins, if I want to get to root from a remote login I login as myself (one password) and then su to root (another password).
However I want to allow root login from one other system on the local LAN. To this end I added the following to the end of sshd_config:-
PasswordAuthentication no AllowUsers root@192.168.1.7
However this, of course, prevents anyone logging in from anywhere except for root@192.168.1.7.
How can I allow any non-root user from anywhere but root only from 192.168.1.7?
On Sun, Dec 14, 2008 at 06:52:55PM +0000, Chris G wrote:
By default I have sshd set up to disallow root logins, if I want to get to root from a remote login I login as myself (one password) and then su to root (another password).
However I want to allow root login from one other system on the local LAN. To this end I added the following to the end of sshd_config:-
PasswordAuthentication no AllowUsers root@192.168.1.7However this, of course, prevents anyone logging in from anywhere except for root@192.168.1.7.
How can I allow any non-root user from anywhere but root only from 192.168.1.7?
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-password
As 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.
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 ?
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.
On Mon, Dec 15, 2008 at 01:30:14AM +0000, 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 ?
You're right about the specific purpose, it's so it can do 'pull' backups, i.e. copy data to 192.168.1.7 (which is the backup machine) from the machine it's logging in to.
I think your sudo approach would probably work too and is probably marginally more secure for some cases.
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.
I've gone to some lengths to make 192.168.1.7 difficult to get to, no ssh root logins are allowed so to get to root you have first to login as a non-root user (needs a password) and then su to root (needs another password).
In addition since what I'm doing is backups the program the sudo user could run is rdiff-backup which would enable them to do just about anything - copy files, overwrite files, delete files (including all the ssh keys of course!).
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.
Cheers,
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.
On 15 Dec 11:56, Chris G wrote:
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.
Hmm, so I'm assuming that will allow any root command to run, then...
I'd suggest that's not a good idea overall ;)
On Mon, Dec 15, 2008 at 12:51:38PM +0000, Brett Parker wrote:
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.
Hmm, so I'm assuming that will allow any root command to run, then...
I'd suggest that's not a good idea overall ;)
As I said I hardly matters as the command that needs to work is a backup command so anyone who can run the command can do just about anything they want - copy files, delete files, overwrite files, etc. They can also of course change the ssh_config file and/or the authorized_keys file so it matters not what you put in there really once someone has root access on 192.168.1.7.
On Mon, 15 Dec 2008, Chris G wrote:
As I said I hardly matters as the command that needs to work is a backup command so anyone who can run the command can do just about anything they want - copy files, delete files, overwrite files, etc.
According to its manpage, super has the capability to restrict what arguments are given to a command as well as the command itself. I'm guessing sudo has similar functionality available, right?
On Mon, Dec 15, 2008 at 11:32:12PM +0000, Dan Hatton wrote:
On Mon, 15 Dec 2008, Chris G wrote:
As I said I hardly matters as the command that needs to work is a backup command so anyone who can run the command can do just about anything they want - copy files, delete files, overwrite files, etc.
According to its manpage, super has the capability to restrict what arguments are given to a command as well as the command itself. I'm guessing sudo has similar functionality available, right?
It descends into a recipe for confusion though doesn't it! :-)
On 15 Dec 23:32, Dan Hatton wrote:
On Mon, 15 Dec 2008, Chris G wrote:
As I said I hardly matters as the command that needs to work is a backup command so anyone who can run the command can do just about anything they want - copy files, delete files, overwrite files, etc.
According to its manpage, super has the capability to restrict what arguments are given to a command as well as the command itself. I'm guessing sudo has similar functionality available, right?
Yes, indeed it does, but it becomes "interesting" to get the recipe right. The fact that the command option in ssh's authorized_keys is well documented, and there are many examples that show how to "safely" set up dirvish via it, not least of all: http://www.uno-code.com/?q=node/10
Now, as that limits the command to only what it trusts, i.e. only what is on the other machine in the authprogs.conf file... and stops *anything* else from running, i.e. there is no copy, delete or overwrite files... (also, sudo or super for firing off a rsync session is going to be a lot more complicated than just firing off the rsync session ;)
Cheers,
On Tue, Dec 16, 2008 at 09:25:43AM +0000, Brett Parker wrote:
On 15 Dec 23:32, Dan Hatton wrote:
On Mon, 15 Dec 2008, Chris G wrote:
As I said I hardly matters as the command that needs to work is a backup command so anyone who can run the command can do just about anything they want - copy files, delete files, overwrite files, etc.
According to its manpage, super has the capability to restrict what arguments are given to a command as well as the command itself. I'm guessing sudo has similar functionality available, right?
Yes, indeed it does, but it becomes "interesting" to get the recipe right. The fact that the command option in ssh's authorized_keys is well documented, and there are many examples that show how to "safely" set up dirvish via it, not least of all: http://www.uno-code.com/?q=node/10
Now, as that limits the command to only what it trusts, i.e. only what is on the other machine in the authprogs.conf file... and stops *anything* else from running, i.e. there is no copy, delete or overwrite files... (also, sudo or super for firing off a rsync session is going to be a lot more complicated than just firing off the rsync session ;)
How do you back up files without copying them? :-)
On 16 Dec 09:55, Chris G wrote:
On Tue, Dec 16, 2008 at 09:25:43AM +0000, Brett Parker wrote:
On 15 Dec 23:32, Dan Hatton wrote:
On Mon, 15 Dec 2008, Chris G wrote:
As I said I hardly matters as the command that needs to work is a backup command so anyone who can run the command can do just about anything they want - copy files, delete files, overwrite files, etc.
According to its manpage, super has the capability to restrict what arguments are given to a command as well as the command itself. I'm guessing sudo has similar functionality available, right?
Yes, indeed it does, but it becomes "interesting" to get the recipe right. The fact that the command option in ssh's authorized_keys is well documented, and there are many examples that show how to "safely" set up dirvish via it, not least of all: http://www.uno-code.com/?q=node/10
Now, as that limits the command to only what it trusts, i.e. only what is on the other machine in the authprogs.conf file... and stops *anything* else from running, i.e. there is no copy, delete or overwrite files... (also, sudo or super for firing off a rsync session is going to be a lot more complicated than just firing off the rsync session ;)
How do you back up files without copying them? :-)
Well, I suspect that it depends on your definition of copy... Now, as far as I'm concerned, what the rsync is actually doing on that end, i.e. the machine being backed up, is serving files, it's not copying anything... unless you count reading from disk to memory as a copy, or from memory to network as a copy... it's not writing anything to the local disk. So, err.
On Tue, Dec 16, 2008 at 10:10:32AM +0000, Brett Parker wrote:
On 16 Dec 09:55, Chris G wrote:
On Tue, Dec 16, 2008 at 09:25:43AM +0000, Brett Parker wrote:
On 15 Dec 23:32, Dan Hatton wrote:
On Mon, 15 Dec 2008, Chris G wrote:
As I said I hardly matters as the command that needs to work is a backup command so anyone who can run the command can do just about anything they want - copy files, delete files, overwrite files, etc.
According to its manpage, super has the capability to restrict what arguments are given to a command as well as the command itself. I'm guessing sudo has similar functionality available, right?
Yes, indeed it does, but it becomes "interesting" to get the recipe right. The fact that the command option in ssh's authorized_keys is well documented, and there are many examples that show how to "safely" set up dirvish via it, not least of all: http://www.uno-code.com/?q=node/10
Now, as that limits the command to only what it trusts, i.e. only what is on the other machine in the authprogs.conf file... and stops *anything* else from running, i.e. there is no copy, delete or overwrite files... (also, sudo or super for firing off a rsync session is going to be a lot more complicated than just firing off the rsync session ;)
How do you back up files without copying them? :-)
Well, I suspect that it depends on your definition of copy... Now, as far as I'm concerned, what the rsync is actually doing on that end, i.e. the machine being backed up, is serving files, it's not copying anything... unless you count reading from disk to memory as a copy, or from memory to network as a copy... it's not writing anything to the local disk. So, err.
It's copying files from the 'remote' machine to 'this' machine, I have the backup running as a cron job on the system where the backups are stored. If that isn't 'copying files' then I don't know what is! :-)
The issue is that as it is running with root privileges it can copy *any* file it likes including all the ssh public and private keys so once you have them you have a pretty free hand to do what you want don't you?
On 16 Dec 12:58, Chris G wrote:
It's copying files from the 'remote' machine to 'this' machine, I have the backup running as a cron job on the system where the backups are stored. If that isn't 'copying files' then I don't know what is! :-)
The issue is that as it is running with root privileges it can copy *any* file it likes including all the ssh public and private keys so once you have them you have a pretty free hand to do what you want don't you?
The remote machine, i.e. the not-backup-server, is purely serving files. Yes, they are being "copied" to the backup box, but I'd hope that the backup box is secured. Having the public/private key pair of the machine that you're backing up isn't going to help, unless your silly and put the locally generated public key in to the authorized_hosts file for that box. Being able to copy *from* is not the same as being able to copy *to*.
Dya get it yet?
On Tue, Dec 16, 2008 at 02:23:01PM +0000, Brett Parker wrote:
On 16 Dec 12:58, Chris G wrote:
It's copying files from the 'remote' machine to 'this' machine, I have the backup running as a cron job on the system where the backups are stored. If that isn't 'copying files' then I don't know what is! :-)
The issue is that as it is running with root privileges it can copy *any* file it likes including all the ssh public and private keys so once you have them you have a pretty free hand to do what you want don't you?
The remote machine, i.e. the not-backup-server, is purely serving files. Yes, they are being "copied" to the backup box, but I'd hope that the backup box is secured. Having the public/private key pair of the machine that you're backing up isn't going to help, unless your silly and put the locally generated public key in to the authorized_hosts file for that box. Being able to copy *from* is not the same as being able to copy *to*.
Dya get it yet?
The *important data* is on the remote machine!!!! That's why I'm backing it up!!!! Yes, I'm trying to make the backup machine a little *more* inaccessible than the other machine but it's really only a "little better".
When all's said and done I'm not trying to secure all this against serious attacks. It's not going to be CIA/MI5 proof, it's probably not proof against concerted (paid for?) attack by another business but I've not got any data they want to know about (well, I don't think I have!). All I'm trying to do is to make my systems fairly safe against most likely attacks and also safe against local disasters like a fire.
-
Brett Parker -
Chris G -
Dan Hatton -
Wayne Stallwood