Re: Trying to elevate rsync privileges when connecting over ssh without using NOPASSWD in sudoers
Hi there, Thanks for your feedback! > Bear in mind, putting a password in an environment variable can be seen by > other users on the same system with "ps auxwwe". Sure. But in my scenario, the control host is considered a „safe“ developer machine, while the target host is considered the „unsafe“ environment. I use this command on my laptop to deploy to lots of cloud machines – there’s noone other than me on my laptop (hopefully ;-)), but instead, I’d like to keep the target machine configurations as secure as possible (no passwordless sudo, no root login). > The environment variables of a process when it was started are available via > /proc//environ file. So while other users on that system can't see the > environ, every other process running as your target user could. > > Worse, however, your "echo" process puts the password in arguments, and any > local user can see program name and args for all running processes. That's a > no-no. Hm, I’m not sure I understand the implications. The whole password handling happens on the machine where I execute rsync (it’s done in "--rsh" not in "--rsync-path“) – which in my scenario is a developer’s laptop. So it’s not the target users that can see the environment but only my own account on my own developer machine. Plus, I don’t understand what you mean with „putting the password in arguments“. The environment variable expansion happens on my control machine exactly at the time when rsync tries to establish a connection to the target machine by running the shell code from --rsh inside a shell. This will create a subshell for echo and cat where the environment variable is read and written to stdout. stdout is then piped through ssh to the remote machine where "sudo -S" reads it on its stdin. It is never in any argument list. Please correct me if I’m wrong here. Best, Mark smime.p7s Description: S/MIME cryptographic signature -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Trying to elevate rsync privileges when connecting over ssh without using NOPASSWD in sudoers
Hi there, hi past me,
> My (non-working) attempt:
> […]
> So it seems the "-l" is dropped into the void letting ssh assume USER was the
> target host? I don’t actually get what I can do.
Turns out, I have to write down the description of my issue and then send the
email before I magically understand the solution ;-)
Here’s a working example that does not need a wrapper script:
PASSWORD= rsync -vv --delete-after --delay-updates '/bin/sh -c "{
echo $PASSWORD; cat - ; } | ssh -i ~/.ssh/id.key $0 $* &"' --rsync-path='sudo
-S rsync‘ ./SRCDIR USER@HOST:DSTDIR
The trick was actually to add "$0" because $* will drop the first argument from
the list as this typically is the name of the script itself (duh!).
Hope this is of help to anyone,
Mark
smime.p7s
Description: S/MIME cryptographic signature
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Trying to elevate rsync privileges when connecting over ssh without using NOPASSWD in sudoers
Hi everyone,
Thanks for all the ideas! Meanwhile, I’ve made some progress because there was
another answer on "ask ubuntu" that got absolutely no interaction but that is a
brilliant solution:
https://askubuntu.com/a/1263657 :
> just create a wrapper script for the ssh command.
> ssh_sudo:
> {
> echo $PASSWORD;
> cat - ;
> } | ssh $* &
>
> At first, this passes the password to the ssh client's sudo process in order
> to start rsync on the remote side. Next all input coming from the local rsync
> is piped to ssh.
> Finally call rsync e.g. with:
> PASSWORD= rsync -avzue ssh_sudo --rsync-path "sudo -S rsync" SRC DST
>
> I guess the security aspect here is not that bad, you'll only have to save
> the password locally as env var. Reading it from a file should work as well...
As it doesn’t need an argpass-script on the target side, but uses a wrapper for
ssh on the HOST side to inject the password from an environment variable, it’s
pretty convenient for my use case. Plus, there’s the added bonus of not having
the password logged anywhere.
Ideally, I would now like to get rid of the helper script, so it’s a single
rsync command that is left. I’m struggling with this but there’ll hopefully be
some bash quoting wizards that can tell me where the issue is.
My (non-working) attempt:
PASSWORD= rsync -vv --delete-after --delay-updates '/bin/sh -c "{
echo $PASSWORD; cat - ; } | ssh -i ~/.ssh/id.key $* &"' --rsync-path='sudo -S
rsync‘ ./SRCDIR USER@HOST:DSTDIR
This get’s mangled by rsync in some non-working way, but I actually don’t
understand enough of shell magic to solve this:
opening connection using: /bin/sh -c "{ echo $PASSWORD; cat - ; } | ssh -i
~/.ssh/id.key $* &" -l USER HOST "sudo -S rsync" --server -vvvlDtrze.iLsfxCIvu
"--log-format=%i" --delete-after --delay-updates . DESTDIR (14 args)
ssh: Could not resolve hostname USER: nodename nor servname provided, or not
known
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(228)
[sender=3.2.3]
So it seems the "-l" is dropped into the void letting ssh assume USER was the
target host? I don’t actually get what I can do.
Anyway, I think the original answer on "ask ubuntu" is quite helpful.
Unfortunately, I don’t have enough „reputation points“ to upvote the answer nor
to comment …
Happy syncing,
Mark
smime.p7s
Description: S/MIME cryptographic signature
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Trying to elevate rsync privileges when connecting over ssh without using NOPASSWD in sudoers
Hi Dan, > Why not rsync directly as root? Then you can use a passwordless, > passphraseless RSA (or similar) keypair. That’s because these are cloud instances that get maintained by multiple admins. If we require all of them to log in as root, we would have to share the root password – and that would on one hand be a security/maintainability issue (if one person leaves the team, we’ll have to change and redistribute the root password), on the other hand it would violate accountability (log files would only show logins by „root“ and after an issue, there would be no chance to know whom to ask about strange things). Both are the typical reasons for not using root accounts but going for sudo instead … Thanks anyway. Every idea helps! Mark smime.p7s Description: S/MIME cryptographic signature -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Trying to elevate rsync privileges when connecting over ssh without using NOPASSWD in sudoers
Hi there, We are using ansible to deploy system configuration and web application source code to clusters of Linux computers. One part of this process requires transferring large directories to the target hosts, which is done using the „synchronize“ command in ansible that is in turn a wrapper around rsync. This work great in most scenarios, but we run into an issue with a specific (albeit for us: prominent) use case: - We try to have rsync connect over ssh using a non-privileged user account. - The account is set up for publickey authentication, so we can use ‚rsync -e „ssh -i /home/user/.ssh/some_id“‘. - On the target side, we want to escalate privileges for rsync, which we try using ‚rsync --rsync-path=„sudo rsync“‘. This whole scenario works fine, as long as for the ssh account we use for logging in, passwordless sudo is set up on the target. For security reasons, we do not want to go this route. Instead, we want to supply the user’s password for gaining privileges. On the web, I’ve found to suggestions for solving this: a) Using ssh-askpass, we can use the options -e "ssh -X" --rsync-path="sudo -A rsync" (see https://askubuntu.com/a/1167758). The problem in our scenario is that using ansible, we run the identical rsync command on multiple hosts in parallel (we target about 32 VMs in one go). So the person running the script would have to enter the password into 32 dialogs exactly at the time they pop up. b) Passing the password to sudo via stdin using --rsync-path "echo MYPASSWORD | sudo -S rsync" (see https://askubuntu.com/a/1155897). This has the potential security implication that if the calling line is stored somewhere in a shell history file of the control host, the password will be breached, but there’s a couple of measures we can take so mitigate that. However, I fail at getting this to run. Here’s a sample command that I get out of a patched ansible „synchronize“ command. I’m trying to connect to a Ubuntu 18.04 VM with the user account „mark“ that is in the „sudoers“ group but does not have „NOPASSWD“ set, so running „sudo“ for the first time in a session will require to enter the password for „mark“ which here is „test“: rsync --delay-updates -F --compress --delete-after --archive --no-perms --no-owner --no-group --rsh='/usr/bin/ssh -S none -i ~/ssh/some_private_key -o Port"22 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null' --rsync-path='echo test | sudo -S -u root rsync 2>/dev/null' --out-format='<>%i %n%L' ~/test_source_dir mark@127.0.0.1:/some/test_target_dir This is what I get: > Warning: Permanently added '[127.0.0.1]:' (ED25519) to the list of known > hosts. > rsync: connection unexpectedly closed (0 bytes received so far) [sender] As far as I understand, this could be due to "sudo -S" prompting for the password and that prompt interfering with the rsync communications. However, I’m out of ideas what I could do to get around that. Help would be greatly appreciated ;-) Thanks and greetings from Cologne, Mark smime.p7s Description: S/MIME cryptographic signature -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
