Re: [gentoo-user] Copying a file via ssh with no password, keeping the system safe
On Fri, Oct 08, 2010 at 10:05:50AM +0200, Andrea Conti wrote: > Now, the remote sshd is never sent any information about what is > connected to the local end of the pipe (which is not even known to > ssh!), so there is no way to alter its behavior depending on that. > > IOW, nothing in the setup you and I proposed prevents the user from > piping an arbitrary command into ssh (or even using a ssh-invoking > wrapper such as scp or rsync) and getting successfully authenticated on > the server. You are only guaranteed that the server will run tar in > place of whatever remote command the client requests, so that the > connection will break if the client side sends non-tar data. > > In my opinion this is quite different from "[allowing] only one single > command from a single cronjob to operate passwordless", but then I might > just be splitting hairs. Okay, reading your explanation I agree with you on both counts: the behaviour does not exactly fit the letter of the question, and that you are splitting hairs because I think the behaviour is good enough for the spirit of the message. Cheers, W -- Willie W. Wong ww...@math.princeton.edu Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire et vice versa ~~~ I. Newton
Re: [gentoo-user] Copying a file via ssh with no password, keeping the system safe
On Thu, 7 Oct 2010 15:38:24 -0700 (PDT), BRM wrote: > > I think for ssh to work the user needs a valid shell, not nologin, so > > you can't do both of those suggestions.] > > Wouldn't a shell-less account per just provide the ability to use > SFTP/SCP? Those don't require a shell to operate. Yes, and also things like rsync. -- Neil Bothwick In plumbing, a straight flush is better than a full house. signature.asc Description: PGP signature
Re: [gentoo-user] Copying a file via ssh with no password, keeping the system safe
On 08/10/2010 0:28, Willie Wong wrote: >> You can't do that on a per-command basis. You'd be trying to control the >> authentication method accepted by sshd on B according to which command >> is run on A -- something sshd on B knows nothing about. >> > > That's partially false. See my response in this thread. Why? SSH can do a lot of things, but when used in the way we're discussing here it just sets up one or more authenticated and encrypted channels between two endpoints; ignoring the details, each one of these roughly acts as a couple of pipes, mutually connecting stdin/stdout of a pair of processes. When you ssh to a remote host, the remote host's sshd will run a command and attach the newly created process to the remote end of the connection; The name of the command is usually passed by the client, but can be overridden on the server either through the sshd configuration files (globally or per-client) or with a per-key 'command' option. Now, the remote sshd is never sent any information about what is connected to the local end of the pipe (which is not even known to ssh!), so there is no way to alter its behavior depending on that. IOW, nothing in the setup you and I proposed prevents the user from piping an arbitrary command into ssh (or even using a ssh-invoking wrapper such as scp or rsync) and getting successfully authenticated on the server. You are only guaranteed that the server will run tar in place of whatever remote command the client requests, so that the connection will break if the client side sends non-tar data. In my opinion this is quite different from "[allowing] only one single command from a single cronjob to operate passwordless", but then I might just be splitting hairs. andrea
Re: [gentoo-user] Copying a file via ssh with no password, keeping the system safe
- Original Message > From: "cov...@ccs.covici.com" > To: gentoo-user@lists.gentoo.org > Sent: Thu, October 7, 2010 6:21:15 PM > Subject: Re: [gentoo-user] Copying a file via ssh with no password, keeping > the >system safe > > Momesso Andrea wrote: > > > > > Quoting Andrea Conti : > > > > > On 07/10/2010 18:45, Momesso Andrea wrote: > > > > > >> Setting up a public key, would do the job, but then, all the connections > > >> between the servers would be passwordless, so if server A gets > > >> compromised, also server B is screwed. > > > > > > Well, not really... public key authentication works on a per-user basis, > > > so all you get is that some user with a specific key can log in as some > > > other user of B without typing a password. > > > > > > Of course, if you authorize a given key for logging in as r...@b, then > > > what you said is true. But that is a problem with the specific setup. > > > > > >> Is there a way to allow only one single command from a single cronjob to > > >> operate passwordless, while keeping all the other connections secured by > > >> a password? > > > > > > You can't do that on a per-command basis. You'd be trying to control the > > > authentication method accepted by sshd on B according to which command > > > is run on A -- something sshd on B knows nothing about. > > > > > > I would try the following way: > > > > > > - Set up an unprivileged user on B -- let's call it foo -- which can > > > only write to its own home directory, /home/foo. > > > > > > - add the public key you will be using (*) to f...@b's authorized_keys > > > file. You should set the key's options to > > > 'pattern="",no-pty,command="/usr/bin/scp -t -- /home/foo"' > > > (man sshd for details). > > > > > > - chattr +i /home/foo/.ssh/authorized_keys, so that the file can only be > > > changed by a superuser (you can't just chown the file to root as sshd is > > > quite anal about the permissions of the authorized_keys file) > > > > > > Now your cron job on A can do "scp f...@b:/home/foo" without the > > > need for entering a password; you just have to set up another cron job > > > on B that picks up the file from /home/foo and puts it where it should > > > go with the correct permissions, possibly after doing a sanity check on > > > its contents. > > > > > > If you use something else than scp, (e.g. rsync) you should also adjust > > > the command option in the key options above. > > > Note that the option refers to what is run on B, not on A. Also, it is > > > *not* an authorization directive à la /etc/sudoers (i.e., it does not > > > specify what commands the user is allowed to run): it simply overwrites > > > whichever command is requested by the client side of the ssh connection, > > > so that, for example, the client cannot request a shell or do "cat > > > ". > > > > > > (*) You can either use the key of the user running the cron job on A, or > > > generate a separate key which is only used for the copy operation. In > > > this case, you will need to tell scp the location of the private key > > > file with the -i option. > > > > > > HTH, > > > andrea > > > > > > > > > > Thank you all for your fast replies, I think I'll use all of your >suggestions: > > > > -create an unprivilegied user with no shell access as Stroller and > > Andrea suggested > > > > -I'll setup a passwordless key for this user, only limited to a single > > command, as Willie > > suggested > > > > This sounds pretty sane to me. > I think for ssh to work the user needs a valid shell, not nologin, so > you can't do both of those suggestions.] Wouldn't a shell-less account per just provide the ability to use SFTP/SCP? Those don't require a shell to operate. You only need a shell if you are going to actually login as a user and do something other than a file transfer. Also, ssh can be run in multiple modes - some of which do not require a shell; for example: ssh someu...@myhost.com /bin/false will run the command "/bin/false" without initiating a shell. (man ssh for details). $0.02 Ben
Re: [gentoo-user] Copying a file via ssh with no password, keeping the system safe
On Thu, Oct 07, 2010 at 08:40:31PM +0200, Andrea Conti wrote: > > Is there a way to allow only one single command from a single cronjob to > > operate passwordless, while keeping all the other connections secured by > > a password? > > You can't do that on a per-command basis. You'd be trying to control the > authentication method accepted by sshd on B according to which command > is run on A -- something sshd on B knows nothing about. > That's partially false. See my response in this thread. W -- Willie W. Wong ww...@math.princeton.edu Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire et vice versa ~~~ I. Newton
Re: [gentoo-user] Copying a file via ssh with no password, keeping the system safe
Momesso Andrea wrote: > > Quoting Andrea Conti : > > > On 07/10/2010 18:45, Momesso Andrea wrote: > > > >> Setting up a public key, would do the job, but then, all the connections > >> between the servers would be passwordless, so if server A gets > >> compromised, also server B is screwed. > > > > Well, not really... public key authentication works on a per-user basis, > > so all you get is that some user with a specific key can log in as some > > other user of B without typing a password. > > > > Of course, if you authorize a given key for logging in as r...@b, then > > what you said is true. But that is a problem with the specific setup. > > > >> Is there a way to allow only one single command from a single cronjob to > >> operate passwordless, while keeping all the other connections secured by > >> a password? > > > > You can't do that on a per-command basis. You'd be trying to control the > > authentication method accepted by sshd on B according to which command > > is run on A -- something sshd on B knows nothing about. > > > > I would try the following way: > > > > - Set up an unprivileged user on B -- let's call it foo -- which can > > only write to its own home directory, /home/foo. > > > > - add the public key you will be using (*) to f...@b's authorized_keys > > file. You should set the key's options to > > 'pattern="",no-pty,command="/usr/bin/scp -t -- /home/foo"' > > (man sshd for details). > > > > - chattr +i /home/foo/.ssh/authorized_keys, so that the file can only be > > changed by a superuser (you can't just chown the file to root as sshd is > > quite anal about the permissions of the authorized_keys file) > > > > Now your cron job on A can do "scp f...@b:/home/foo" without the > > need for entering a password; you just have to set up another cron job > > on B that picks up the file from /home/foo and puts it where it should > > go with the correct permissions, possibly after doing a sanity check on > > its contents. > > > > If you use something else than scp, (e.g. rsync) you should also adjust > > the command option in the key options above. > > Note that the option refers to what is run on B, not on A. Also, it is > > *not* an authorization directive à la /etc/sudoers (i.e., it does not > > specify what commands the user is allowed to run): it simply overwrites > > whichever command is requested by the client side of the ssh connection, > > so that, for example, the client cannot request a shell or do "cat > > ". > > > > (*) You can either use the key of the user running the cron job on A, or > > generate a separate key which is only used for the copy operation. In > > this case, you will need to tell scp the location of the private key > > file with the -i option. > > > > HTH, > > andrea > > > > > > Thank you all for your fast replies, I think I'll use all of your suggestions: > > -create an unprivilegied user with no shell access as Stroller and > Andrea suggested > > -I'll setup a passwordless key for this user, only limited to a single > command, as Willie > suggested > > This sounds pretty sane to me. I think for ssh to work the user needs a valid shell, not nologin, so you can't do both of those suggestions.] -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] Copying a file via ssh with no password, keeping the system safe
Quoting Andrea Conti : On 07/10/2010 18:45, Momesso Andrea wrote: Setting up a public key, would do the job, but then, all the connections between the servers would be passwordless, so if server A gets compromised, also server B is screwed. Well, not really... public key authentication works on a per-user basis, so all you get is that some user with a specific key can log in as some other user of B without typing a password. Of course, if you authorize a given key for logging in as r...@b, then what you said is true. But that is a problem with the specific setup. Is there a way to allow only one single command from a single cronjob to operate passwordless, while keeping all the other connections secured by a password? You can't do that on a per-command basis. You'd be trying to control the authentication method accepted by sshd on B according to which command is run on A -- something sshd on B knows nothing about. I would try the following way: - Set up an unprivileged user on B -- let's call it foo -- which can only write to its own home directory, /home/foo. - add the public key you will be using (*) to f...@b's authorized_keys file. You should set the key's options to 'pattern="",no-pty,command="/usr/bin/scp -t -- /home/foo"' (man sshd for details). - chattr +i /home/foo/.ssh/authorized_keys, so that the file can only be changed by a superuser (you can't just chown the file to root as sshd is quite anal about the permissions of the authorized_keys file) Now your cron job on A can do "scp f...@b:/home/foo" without the need for entering a password; you just have to set up another cron job on B that picks up the file from /home/foo and puts it where it should go with the correct permissions, possibly after doing a sanity check on its contents. If you use something else than scp, (e.g. rsync) you should also adjust the command option in the key options above. Note that the option refers to what is run on B, not on A. Also, it is *not* an authorization directive à la /etc/sudoers (i.e., it does not specify what commands the user is allowed to run): it simply overwrites whichever command is requested by the client side of the ssh connection, so that, for example, the client cannot request a shell or do "cat ". (*) You can either use the key of the user running the cron job on A, or generate a separate key which is only used for the copy operation. In this case, you will need to tell scp the location of the private key file with the -i option. HTH, andrea Thank you all for your fast replies, I think I'll use all of your suggestions: -create an unprivilegied user with no shell access as Stroller and Andrea suggested -I'll setup a passwordless key for this user, only limited to a single command, as Willie suggested This sounds pretty sane to me. TopperH http://topperh.ath.cx This message was sent using IMP, the Internet Messaging Program.
Re: [gentoo-user] Copying a file via ssh with no password, keeping the system safe
On 07/10/2010 18:45, Momesso Andrea wrote: > Setting up a public key, would do the job, but then, all the connections > between the servers would be passwordless, so if server A gets > compromised, also server B is screwed. Well, not really... public key authentication works on a per-user basis, so all you get is that some user with a specific key can log in as some other user of B without typing a password. Of course, if you authorize a given key for logging in as r...@b, then what you said is true. But that is a problem with the specific setup. > Is there a way to allow only one single command from a single cronjob to > operate passwordless, while keeping all the other connections secured by > a password? You can't do that on a per-command basis. You'd be trying to control the authentication method accepted by sshd on B according to which command is run on A -- something sshd on B knows nothing about. I would try the following way: - Set up an unprivileged user on B -- let's call it foo -- which can only write to its own home directory, /home/foo. - add the public key you will be using (*) to f...@b's authorized_keys file. You should set the key's options to 'pattern="",no-pty,command="/usr/bin/scp -t -- /home/foo"' (man sshd for details). - chattr +i /home/foo/.ssh/authorized_keys, so that the file can only be changed by a superuser (you can't just chown the file to root as sshd is quite anal about the permissions of the authorized_keys file) Now your cron job on A can do "scp f...@b:/home/foo" without the need for entering a password; you just have to set up another cron job on B that picks up the file from /home/foo and puts it where it should go with the correct permissions, possibly after doing a sanity check on its contents. If you use something else than scp, (e.g. rsync) you should also adjust the command option in the key options above. Note that the option refers to what is run on B, not on A. Also, it is *not* an authorization directive à la /etc/sudoers (i.e., it does not specify what commands the user is allowed to run): it simply overwrites whichever command is requested by the client side of the ssh connection, so that, for example, the client cannot request a shell or do "cat ". (*) You can either use the key of the user running the cron job on A, or generate a separate key which is only used for the copy operation. In this case, you will need to tell scp the location of the private key file with the -i option. HTH, andrea
Re: [gentoo-user] Copying a file via ssh with no password, keeping the system safe
On Thu, Oct 07, 2010 at 02:14:47PM -0400, Willie Wong wrote: > On Thu, Oct 07, 2010 at 06:45:49PM +0200, Momesso Andrea wrote: > > I need to set up a cron job to transfer a file every day from server A > > to server B. > > > > I'd like to do that via ssh and with no user assistance, completely > > automated. > > > > Setting up a public key, would do the job, but then, all the > > connections between the servers would be passwordless, so if server A > > gets compromised, also server B is screwed. > > > > Is there a way to allow only one single command from a single cronjob > > to operate passwordless, while keeping all the other connections > > secured by a password? > > In the authorized_keys file, you need to include a specification of > "command=". Which means that on log-in with the > public key, the sshd will execute that command, and any other commands > sent from the machine which originated the connection will not > execute. > > So I'd imagine you can untar with the command at the target, and > instead of scp, use something like > > tar | ssh -i u...@host > These two links may also be helpful: http://www.debian-administration.org/articles/438 http://sial.org/howto/rsync/ W -- Willie W. Wong ww...@math.princeton.edu Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire et vice versa ~~~ I. Newton
Re: [gentoo-user] Copying a file via ssh with no password, keeping the system safe
On Thu, Oct 07, 2010 at 06:45:49PM +0200, Momesso Andrea wrote: > I need to set up a cron job to transfer a file every day from server A > to server B. > > I'd like to do that via ssh and with no user assistance, completely > automated. > > Setting up a public key, would do the job, but then, all the > connections between the servers would be passwordless, so if server A > gets compromised, also server B is screwed. > > Is there a way to allow only one single command from a single cronjob > to operate passwordless, while keeping all the other connections > secured by a password? In the authorized_keys file, you need to include a specification of "command=". Which means that on log-in with the public key, the sshd will execute that command, and any other commands sent from the machine which originated the connection will not execute. So I'd imagine you can untar with the command at the target, and instead of scp, use something like tar | ssh -i u...@host (of course, this still opens up the possibility that a partition gets filled on your target machine by someone copying random string to it, but you'd have to live with that). (Also, note, I haven't actually tried this method of copying files myself, so while I'd imagine it'd work, you may need to play around with it for a bit. What I've done before was to have a shell script set to run, triggered by a public key login like this.) See 'man sshd' for more detail. HTH, W -- Willie W. Wong ww...@math.princeton.edu Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire et vice versa ~~~ I. Newton
Re: [gentoo-user] Copying a file via ssh with no password, keeping the system safe
On 7 Oct 2010, at 17:45, Momesso Andrea wrote: > I need to set up a cron job to transfer a file every day from server A to > server B. > > I'd like to do that via ssh and with no user assistance, completely automated. > > Setting up a public key, would do the job, but then, all the connections > between the servers would be passwordless, so if server A gets compromised, > also server B is screwed. > > Is there a way to allow only one single command from a single cronjob to > operate passwordless, while keeping all the other connections secured by a > password? You could create a user on server B called backup, a user with very limited permissions and no shell (/bin/false). Thus server A can transfer files to serverb:~backup but if the key is compromised then little else can be done. Not sure if the user could somehow be run in a chrooted ssh, for better security? I'm not sure what files a new user "backup" would have read-access to by default? If the key is obtained from server A then the attacker could copy files from server B (back to wherever they like), and it might be possible to obtain information about what services are run on that system or otherwise learn vulnerabilities from what could be read. Stroller.
[gentoo-user] Copying a file via ssh with no password, keeping the system safe
Hi list, I need to set up a cron job to transfer a file every day from server A to server B. I'd like to do that via ssh and with no user assistance, completely automated. Setting up a public key, would do the job, but then, all the connections between the servers would be passwordless, so if server A gets compromised, also server B is screwed. Is there a way to allow only one single command from a single cronjob to operate passwordless, while keeping all the other connections secured by a password? Thank you in advance for your help. TopperH http://topperh.ath.cx This message was sent using IMP, the Internet Messaging Program.
