Re: Updating files in /etc Remotely (and automated)
I agree with Jesús. This is a far more elegant and scalable solution, though my experience is with cfengine [1]. This allows you to use svn or cvs to manage the master files, check out the files to your workstation, make changes and commit, and depending on how you have it set up, have the changes automatically propagated. There are actually several similar packages (cfengine = perl-ish, bcfg2 = python-ish, puppet = ruby-on-rails-ish, etc.) They all have the same goal in mind, convergence of system configurations, loosely referred to as configuration management. --b [1] http://www.cfengine.org 2010/9/13 Jesús M. Navarro jesus.nava...@undominio.net Hi, Hal: On Saturday 11 September 2010 23:15:50 Hal Vaughan wrote: I will be working with a server on the Internet that uses rsync and is running Debian. I will be setting up initial /etc/rsyncd.conf and /etc/rsyncd.secrets files on it. But along the way, whenever a new user is added, they'll need to be updated. I can use ssh on this system, but, of course, I don't want to allow root access. I'd like to be able to have these files updated automatically when I add a new user to another system. I could create new copies of the files locally, where the users are added and use scp to copy them to a directory on the server. But that's where there are problems. How can I chown the files to root, copy them to /etc, and chmod as needed for rsync to use them automatically? I know that's not what you specifically asked for, but thinking a bit out-of-the-box, what you have is a need to remotely configure a machine from a central information repository. Have you though about using Puppet*1 for that? *1 http://www.puppetlabs.com Cheers. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201009131456.15818.jesus.nava...@undominio.net
Re: Updating files in /etc Remotely (and automated)
On Sun, 12 Sep 2010 14:31:12 -0400, Hal Vaughan wrote: . . . someone sent it to me privately a little while ago. While I like what Rob Owens suggested, I'm leaning toward this. I think it's possible that I could send up the minimum information in a file and have the cron job be a Perl script that takes that info and builds the rsyncd.conf and rsyncd.secrets files from there, which reduces the possibility of a rogue file being copied over somehow. Still, none of the ideas is perfect, but putting together the conf files on the site, as opposed to sending them directly, has certain merits. Could you post back your chosen solution please? I was looking for solutions for the same situation. Thanks -- Tong (remove underscore(s) to reply) http://xpt.sourceforge.net/techdocs/ http://xpt.sourceforge.net/tools/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/i6uq5l$47...@dough.gmane.org
Re: Updating files in /etc Remotely (and automated)
Hi, Hal: On Saturday 11 September 2010 23:15:50 Hal Vaughan wrote: I will be working with a server on the Internet that uses rsync and is running Debian. I will be setting up initial /etc/rsyncd.conf and /etc/rsyncd.secrets files on it. But along the way, whenever a new user is added, they'll need to be updated. I can use ssh on this system, but, of course, I don't want to allow root access. I'd like to be able to have these files updated automatically when I add a new user to another system. I could create new copies of the files locally, where the users are added and use scp to copy them to a directory on the server. But that's where there are problems. How can I chown the files to root, copy them to /etc, and chmod as needed for rsync to use them automatically? I know that's not what you specifically asked for, but thinking a bit out-of-the-box, what you have is a need to remotely configure a machine from a central information repository. Have you though about using Puppet*1 for that? *1 http://www.puppetlabs.com Cheers. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201009131456.15818.jesus.nava...@undominio.net
Re: Updating files in /etc Remotely (and automated)
On Sat, Sep 11, 2010 at 05:15:50PM -0400, Hal Vaughan wrote: I will be working with a server on the Internet that uses rsync and is running Debian. I will be setting up initial /etc/rsyncd.conf and /etc/rsyncd.secrets files on it. But along the way, whenever a new user is added, they'll need to be updated. I can use ssh on this system, but, of course, I don't want to allow root access. I'd like to be able to have these files updated automatically when I add a new user to another system. I could create new copies of the files locally, where the users are added and use scp to copy them to a directory on the server. But that's where there are problems. How can I chown the files to root, copy them to /etc, and chmod as needed for rsync to use them automatically? I don't see a way to do that without security issues. I need to somehow ssh in and do an su or run three commands as sudo (I need to mv the file, chown it, and chmod it). I am far from an expert in security, but I can see that if I have anything in place to make this easy, then anyone hacking my user account could easily mess up anything in the system. Is there some way I can set this up so I can update rsyncd.conf and rsyncd.secrets only automatically when I have the newer versions on my local system to be uploaded? When using ssh keys to log in, you can specify (in ~/.ssh/authorized_keys) a command which will automatically run when that key is used to log in. And that key will be useless to do anything else. Simply using that key to conenct to the remote server will run that command. The authorized_keys file would look something like this: command=/path/to/my/script ssh-rsa B3NzaC1yc2EAAA m...@myhost You could use this to ssh into the remote server as root, or as a user with very specify sudo privileges that will allow your script to run. (The script would perform the file changes you need done, or simply rsync them from your local machine). -Rob -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100912145107.ga29...@aurora.owens.net
Re: Updating files in /etc Remotely (and automated)
On Sep 12, 2010, at 10:51 AM, Rob Owens wrote: On Sat, Sep 11, 2010 at 05:15:50PM -0400, Hal Vaughan wrote: I will be working with a server on the Internet that uses rsync and is running Debian. I will be setting up initial /etc/rsyncd.conf and /etc/rsyncd.secrets files on it. But along the way, whenever a new user is added, they'll need to be updated. I can use ssh on this system, but, of course, I don't want to allow root access. I'd like to be able to have these files updated automatically when I add a new user to another system. I could create new copies of the files locally, where the users are added and use scp to copy them to a directory on the server. But that's where there are problems. How can I chown the files to root, copy them to /etc, and chmod as needed for rsync to use them automatically? I don't see a way to do that without security issues. I need to somehow ssh in and do an su or run three commands as sudo (I need to mv the file, chown it, and chmod it). I am far from an expert in security, but I can see that if I have anything in place to make this easy, then anyone hacking my user account could easily mess up anything in the system. Is there some way I can set this up so I can update rsyncd.conf and rsyncd.secrets only automatically when I have the newer versions on my local system to be uploaded? When using ssh keys to log in, you can specify (in ~/.ssh/authorized_keys) a command which will automatically run when that key is used to log in. And that key will be useless to do anything else. Simply using that key to conenct to the remote server will run that command. The authorized_keys file would look something like this: command=/path/to/my/script ssh-rsa B3NzaC1yc2EAAA m...@myhost I see. That would make perfect sense and I see I can use -i to specify which key to use, so for normal situations, I just use ssh host, and when I want this done, I do ssh -i .ssh/special_key host instead. I thought I knew about authorized keys, but didn't know you could specify a command to be run in that file. You could use this to ssh into the remote server as root, or as a user with very specify sudo privileges that will allow your script to run. (The script would perform the file changes you need done, or simply rsync them from your local machine). But if I'm not running as root, from what I can see, no matter what I do with sudo, I still have to type in a password, don't I? using the authorized_keys file and specifying what can be done at login does a lot to help with security, but if I don't log in as root, no matter what I do, I'll still have to type in a password to use either su or sudo, right? Or is there a way around it? I was going through man pages, but it seems both require a password to be typed in no matter what. Hal -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/9229c387-bb4b-4004-834a-3bea7fa77...@halblog.com
Re: Updating files in /etc Remotely (and automated)
On Sun, Sep 12, 2010 at 12:01:26PM -0400, Hal Vaughan wrote: On Sep 12, 2010, at 10:51 AM, Rob Owens wrote: On Sat, Sep 11, 2010 at 05:15:50PM -0400, Hal Vaughan wrote: I will be working with a server on the Internet that uses rsync and is running Debian. I will be setting up initial /etc/rsyncd.conf and /etc/rsyncd.secrets files on it. But along the way, whenever a new user is added, they'll need to be updated. I can use ssh on this system, but, of course, I don't want to allow root access. I'd like to be able to have these files updated automatically when I add a new user to another system. I could create new copies of the files locally, where the users are added and use scp to copy them to a directory on the server. But that's where there are problems. How can I chown the files to root, copy them to /etc, and chmod as needed for rsync to use them automatically? I don't see a way to do that without security issues. I need to somehow ssh in and do an su or run three commands as sudo (I need to mv the file, chown it, and chmod it). I am far from an expert in security, but I can see that if I have anything in place to make this easy, then anyone hacking my user account could easily mess up anything in the system. Is there some way I can set this up so I can update rsyncd.conf and rsyncd.secrets only automatically when I have the newer versions on my local system to be uploaded? When using ssh keys to log in, you can specify (in ~/.ssh/authorized_keys) a command which will automatically run when that key is used to log in. And that key will be useless to do anything else. Simply using that key to conenct to the remote server will run that command. The authorized_keys file would look something like this: command=/path/to/my/script ssh-rsa B3NzaC1yc2EAAA m...@myhost I see. That would make perfect sense and I see I can use -i to specify which key to use, so for normal situations, I just use ssh host, and when I want this done, I do ssh -i .ssh/special_key host instead. I thought I knew about authorized keys, but didn't know you could specify a command to be run in that file. You could use this to ssh into the remote server as root, or as a user with very specify sudo privileges that will allow your script to run. (The script would perform the file changes you need done, or simply rsync them from your local machine). But if I'm not running as root, from what I can see, no matter what I do with sudo, I still have to type in a password, don't I? using the authorized_keys file and specifying what can be done at login does a lot to help with security, but if I don't log in as root, no matter what I do, I'll still have to type in a password to use either su or sudo, right? Or is there a way around it? I was going through man pages, but it seems both require a password to be typed in no matter what. In /etc/sudoers, you can specify NOPASSWD, like this: someuserALL=NOPASSWD: /path/to/some/command Then someuser can run the specified command as root without typing a password. -Rob -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100912163733.gb29...@aurora.owens.net
Re: Updating files in /etc Remotely (and automated)
On Sep 12, 2010, at 12:37 PM, Rob Owens wrote: On Sun, Sep 12, 2010 at 12:01:26PM -0400, Hal Vaughan wrote: On Sep 12, 2010, at 10:51 AM, Rob Owens wrote: On Sat, Sep 11, 2010 at 05:15:50PM -0400, Hal Vaughan wrote: I will be working with a server on the Internet that uses rsync and is running Debian. I will be setting up initial /etc/rsyncd.conf and /etc/rsyncd.secrets files on it. But along the way, whenever a new user is added, they'll need to be updated. I can use ssh on this system, but, of course, I don't want to allow root access. I'd like to be able to have these files updated automatically when I add a new user to another system. I could create new copies of the files locally, where the users are added and use scp to copy them to a directory on the server. But that's where there are problems. How can I chown the files to root, copy them to /etc, and chmod as needed for rsync to use them automatically? I don't see a way to do that without security issues. I need to somehow ssh in and do an su or run three commands as sudo (I need to mv the file, chown it, and chmod it). I am far from an expert in security, but I can see that if I have anything in place to make this easy, then anyone hacking my user account could easily mess up anything in the system. Is there some way I can set this up so I can update rsyncd.conf and rsyncd.secrets only automatically when I have the newer versions on my local system to be uploaded? When using ssh keys to log in, you can specify (in ~/.ssh/authorized_keys) a command which will automatically run when that key is used to log in. And that key will be useless to do anything else. Simply using that key to conenct to the remote server will run that command. The authorized_keys file would look something like this: command=/path/to/my/script ssh-rsa B3NzaC1yc2EAAA m...@myhost I see. That would make perfect sense and I see I can use -i to specify which key to use, so for normal situations, I just use ssh host, and when I want this done, I do ssh -i .ssh/special_key host instead. I thought I knew about authorized keys, but didn't know you could specify a command to be run in that file. You could use this to ssh into the remote server as root, or as a user with very specify sudo privileges that will allow your script to run. (The script would perform the file changes you need done, or simply rsync them from your local machine). But if I'm not running as root, from what I can see, no matter what I do with sudo, I still have to type in a password, don't I? using the authorized_keys file and specifying what can be done at login does a lot to help with security, but if I don't log in as root, no matter what I do, I'll still have to type in a password to use either su or sudo, right? Or is there a way around it? I was going through man pages, but it seems both require a password to be typed in no matter what. In /etc/sudoers, you can specify NOPASSWD, like this: someuser ALL=NOPASSWD: /path/to/some/command Then someuser can run the specified command as root without typing a password. My bad, in this case. I read the SUDO man page over a few times, but forgot to read SUDOERS man page. Thanks! Hal -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/dd0542fe-3b19-4d26-a129-b03d831b0...@halblog.com
Re: Updating files in /etc Remotely (and automated)
On 11/09/10 22:15, Hal Vaughan wrote: I will be working with a server on the Internet that uses rsync and is running Debian. I will be setting up initial /etc/rsyncd.conf and /etc/rsyncd.secrets files on it. But along the way, whenever a new user is added, they'll need to be updated. I can use ssh on this system, but, of course, I don't want to allow root access. I'd like to be able to have these files updated automatically when I add a new user to another system. I could create new copies of the files locally, where the users are added and use scp to copy them to a directory on the server. But that's where there are problems. How can I chown the files to root, copy them to /etc, and chmod as needed for rsync to use them automatically? I don't see a way to do that without security issues. I need to somehow ssh in and do an su or run three commands as sudo (I need to mv the file, chown it, and chmod it). I am far from an expert in security, but I can see that if I have anything in place to make this easy, then anyone hacking my user account could easily mess up anything in the system. Is there some way I can set this up so I can update rsyncd.conf and rsyncd.secrets only automatically when I have the newer versions on my local system to be uploaded? Thanks for any ideas! Hal How quickly do you need the updates? Cron will run scripts as root, and can run your script as often as you can stand the overhead. You just need to get the files there in a safe way. -- Joe -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c8d11b6.5000...@jretrading.com
Re: Updating files in /etc Remotely (and automated)
On Sep 12, 2010, at 1:45 PM, Joe wrote: On 11/09/10 22:15, Hal Vaughan wrote: I will be working with a server on the Internet that uses rsync and is running Debian. I will be setting up initial /etc/rsyncd.conf and /etc/rsyncd.secrets files on it. But along the way, whenever a new user is added, they'll need to be updated. I can use ssh on this system, but, of course, I don't want to allow root access. I'd like to be able to have these files updated automatically when I add a new user to another system. I could create new copies of the files locally, where the users are added and use scp to copy them to a directory on the server. But that's where there are problems. How can I chown the files to root, copy them to /etc, and chmod as needed for rsync to use them automatically? I don't see a way to do that without security issues. I need to somehow ssh in and do an su or run three commands as sudo (I need to mv the file, chown it, and chmod it). I am far from an expert in security, but I can see that if I have anything in place to make this easy, then anyone hacking my user account could easily mess up anything in the system. Is there some way I can set this up so I can update rsyncd.conf and rsyncd.secrets only automatically when I have the newer versions on my local system to be uploaded? Thanks for any ideas! Hal How quickly do you need the updates? Cron will run scripts as root, and can run your script as often as you can stand the overhead. You just need to get the files there in a safe way. I had completely overlooked that idea and someone sent it to me privately a little while ago. While I like what Rob Owens suggested, I'm leaning toward this. I think it's possible that I could send up the minimum information in a file and have the cron job be a Perl script that takes that info and builds the rsyncd.conf and rsyncd.secrets files from there, which reduces the possibility of a rogue file being copied over somehow. Still, none of the ideas is perfect, but putting together the conf files on the site, as opposed to sending them directly, has certain merits. Thanks! Hal -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/c04810b6-f31e-45a7-ad91-c8d5fe13f...@halblog.com
Re: Updating files in /etc Remotely (and automated)
On Sep 12, 2010, at 12:37 PM, Rob Owens wrote: ... When using ssh keys to log in, you can specify (in ~/.ssh/authorized_keys) a command which will automatically run when that key is used to log in. And that key will be useless to do anything else. Simply using that key to conenct to the remote server will run that command. The authorized_keys file would look something like this: command=/path/to/my/script ssh-rsa B3NzaC1yc2EAAA m...@myhost I see. That would make perfect sense and I see I can use -i to specify which key to use, so for normal situations, I just use ssh host, and when I want this done, I do ssh -i .ssh/special_key host instead. I thought I knew about authorized keys, but didn't know you could specify a command to be run in that file. You could use this to ssh into the remote server as root, or as a user with very specify sudo privileges that will allow your script to run. (The script would perform the file changes you need done, or simply rsync them from your local machine). But if I'm not running as root, from what I can see, no matter what I do with sudo, I still have to type in a password, don't I? using the authorized_keys file and specifying what can be done at login does a lot to help with security, but if I don't log in as root, no matter what I do, I'll still have to type in a password to use either su or sudo, right? Or is there a way around it? I was going through man pages, but it seems both require a password to be typed in no matter what. In /etc/sudoers, you can specify NOPASSWD, like this: someuser ALL=NOPASSWD: /path/to/some/command Then someuser can run the specified command as root without typing a password. When I tested this with some simple scripts, I find if I create a batch file that runs a few commands, like chown root:root filename that those commands, which would normally need the sudo command don't need it. Is this because of the (usually) 5 minute time limit sudo uses? Can I trust this on all systems, or is there anything that could prevent this behavior? In other words, if I include, in the script, commands that also need sudo, am I right that I can count on them executing without further need of verification? Thanks for anyone who can include more info on this! Hal -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/0ea47e68-49ed-4f32-a91b-4379e27e4...@halblog.com
Re: Updating files in /etc Remotely (and automated)
On Sun, Sep 12, 2010 at 02:35:00PM -0400, Hal Vaughan wrote: On Sep 12, 2010, at 12:37 PM, Rob Owens wrote: ... When using ssh keys to log in, you can specify (in ~/.ssh/authorized_keys) a command which will automatically run when that key is used to log in. And that key will be useless to do anything else. Simply using that key to conenct to the remote server will run that command. The authorized_keys file would look something like this: command=/path/to/my/script ssh-rsa B3NzaC1yc2EAAA m...@myhost I see. That would make perfect sense and I see I can use -i to specify which key to use, so for normal situations, I just use ssh host, and when I want this done, I do ssh -i .ssh/special_key host instead. I thought I knew about authorized keys, but didn't know you could specify a command to be run in that file. You could use this to ssh into the remote server as root, or as a user with very specify sudo privileges that will allow your script to run. (The script would perform the file changes you need done, or simply rsync them from your local machine). But if I'm not running as root, from what I can see, no matter what I do with sudo, I still have to type in a password, don't I? using the authorized_keys file and specifying what can be done at login does a lot to help with security, but if I don't log in as root, no matter what I do, I'll still have to type in a password to use either su or sudo, right? Or is there a way around it? I was going through man pages, but it seems both require a password to be typed in no matter what. In /etc/sudoers, you can specify NOPASSWD, like this: someuserALL=NOPASSWD: /path/to/some/command Then someuser can run the specified command as root without typing a password. When I tested this with some simple scripts, I find if I create a batch file that runs a few commands, like chown root:root filename that those commands, which would normally need the sudo command don't need it. Is this because of the (usually) 5 minute time limit sudo uses? Can I trust this on all systems, or is there anything that could prevent this behavior? In other words, if I include, in the script, commands that also need sudo, am I right that I can count on them executing without further need of verification? If you run sudo somescript, then the script runs as root, so every command inside it will run as root. I think it is generally considered smarter, security-wise, to run somescript and then include sudo inside the script as necessary. For instance, your script might look like this: #!/bin/bash # # myscript.sh # sudo ls /root/* ls /home/* #doesn't need root privileges sudo touch /usr/local/somefile This script could be run as a regular user, but it would only run properly if the user had the appropriate sudo rights. -Rob -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100912202459.ga32...@aurora.owens.net
Re: Updating files in /etc Remotely (and automated)
On Sun Sep 12, 2010 at 16:24:59 -0400, Rob Owens wrote: If you run sudo somescript, then the script runs as root, so every command inside it will run as root. I think it is generally considered smarter, security-wise, to run somescript and then include sudo inside the script as necessary. I believe that makes sense in an objective way, but I've never seen that defined as a best practise, and your example fails in a way that suggests you've not done it that way yourself. sudo ls /root/* Fails. Why? Because _your_ shell does the expansion, before passing to sudo. For example compare these two command and outputs: s...@birthday:~$ sudo ls /root/* s...@birthday:~$ s...@birthday:~$ sudo ls /root/ Desktop s...@birthday:~$ Steve -- Let me steal your soul? http://stolen-souls.com -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100912215822.ga26...@steve.org.uk
Re: Updating files in /etc Remotely (and automated)
On Sun, Sep 12, 2010 at 10:58:22PM +0100, Steve Kemp wrote: On Sun Sep 12, 2010 at 16:24:59 -0400, Rob Owens wrote: If you run sudo somescript, then the script runs as root, so every command inside it will run as root. I think it is generally considered smarter, security-wise, to run somescript and then include sudo inside the script as necessary. I believe that makes sense in an objective way, but I've never seen that defined as a best practise, and your example fails in a way that suggests you've not done it that way yourself. sudo ls /root/* Fails. Why? Because _your_ shell does the expansion, before passing to sudo. For example compare these two command and outputs: s...@birthday:~$ sudo ls /root/* s...@birthday:~$ s...@birthday:~$ sudo ls /root/ Desktop s...@birthday:~$ Correct, I didn't test that script myself. It was intended as an example to clarify my explanation. Regarding best practice: If you run your entire script as root, then you introduce the possibility that someone could cause your script to crash in such a way that it gives the attacker root access. How? I'm not sure, but if you run the script as a regular user you can avoid the possibility that somebody else figures out how. I'd say it's probably analagous to running services as a non-privileged user. It's best to do it if you can, because it removes a lot of what if scenarios. -Rob -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100912215900.ga32...@aurora.owens.net
Re: Updating files in /etc Remotely (and automated)
On 12/09/10 21:24, Rob Owens wrote: On Sun, Sep 12, 2010 at 02:35:00PM -0400, Hal Vaughan wrote: On Sep 12, 2010, at 12:37 PM, Rob Owens wrote: ... When using ssh keys to log in, you can specify (in ~/.ssh/authorized_keys) a command which will automatically run when that key is used to log in. And that key will be useless to do anything else. Simply using that key to conenct to the remote server will run that command. The authorized_keys file would look something like this: command=/path/to/my/script ssh-rsa B3NzaC1yc2EAAA m...@myhost I see. That would make perfect sense and I see I can use -i to specify which key to use, so for normal situations, I just use ssh host, and when I want this done, I do ssh -i .ssh/special_key host instead. I thought I knew about authorized keys, but didn't know you could specify a command to be run in that file. You could use this to ssh into the remote server as root, or as a user with very specify sudo privileges that will allow your script to run. (The script would perform the file changes you need done, or simply rsync them from your local machine). But if I'm not running as root, from what I can see, no matter what I do with sudo, I still have to type in a password, don't I? using the authorized_keys file and specifying what can be done at login does a lot to help with security, but if I don't log in as root, no matter what I do, I'll still have to type in a password to use either su or sudo, right? Or is there a way around it? I was going through man pages, but it seems both require a password to be typed in no matter what. In /etc/sudoers, you can specify NOPASSWD, like this: someuserALL=NOPASSWD: /path/to/some/command Then someuser can run the specified command as root without typing a password. When I tested this with some simple scripts, I find if I create a batch file that runs a few commands, like chown root:root filename that those commands, which would normally need the sudo command don't need it. Is this because of the (usually) 5 minute time limit sudo uses? Can I trust this on all systems, or is there anything that could prevent this behavior? In other words, if I include, in the script, commands that also need sudo, am I right that I can count on them executing without further need of verification? If you run sudo somescript, then the script runs as root, so every command inside it will run as root. I think it is generally considered smarter, security-wise, to run somescript and then include sudo inside the script as necessary. For instance, your script might look like this: #!/bin/bash # # myscript.sh # sudo ls /root/* ls /home/* #doesn't need root privileges sudo touch /usr/local/somefile This script could be run as a regular user, but it would only run properly if the user had the appropriate sudo rights. Note that sudo does not completely mimic root behaviour. Commands using , and presumably other composite commands, will depend on the user's own permissions. In an 'all-root' directory, with no existing file2: sudo cp file1 file2 works as expected sudo touch file2 works as expected sudo cat file1 works as expected sudo cat file1 file2 fails due to lack of write permission su -c cat file1 file2, then password, works as expected It isn't just cat, I first noticed this some years ago with aggregate, which also uses . I assume that when the shell reaches the , which is effectively another command, the temporary sudo one-command permission has expired. The trick with the quotation marks doesn't work, sudo expects the entire quoted string to be the name of an executable. -- Joe -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c8d4e6b.7010...@jretrading.com
Re: Updating files in /etc Remotely (and automated)
On 09/12/2010 07:04 PM, Joe wrote: Note that sudo does not completely mimic root behaviour. Commands using , and presumably other composite commands, will depend on the user's own permissions. In an 'all-root' directory, with no existing file2: sudo cp file1 file2 works as expected sudo touch file2 works as expected sudo cat file1 works as expected sudo cat file1 file2 fails due to lack of write permission su -c cat file1 file2, thenpassword, works as expected It isn't just cat, I first noticed this some years ago with aggregate, which also uses. I assume that when the shell reaches the, which is effectively another command, the temporary sudo one-command permission has expired. The trick with the quotation marks doesn't work, sudo expects the entire quoted string to be the name of an executable. Actually, the shell (running as the normal user) sees the redirection, tries to opens the file, and then runs sudo cat file1, redirecting the output to the opened file. Then sudo runs, cat'ing the file (as root) to stdout. -- Do YOU have redeeming social value? Eduardo M KALINOWSKI edua...@kalinowski.com.br -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c8d667b.1070...@kalinowski.com.br
