I'm trying to rsync files with my server, which has root login via ssh disabled. I'm trying to use one of the users I've created and added to to the wheel group. Usually - when I log in via ssh I run
su - root
then type the password and can run everything as root user, but not quite sure how to do it with rsync as I need to upload the files outside of the user directory.
When I run:
rsync -avz files/* sshwheeluser#ip_address:/home/newproject/public_html/
I get:
rsync: ERROR: cannot stat destination "/home/newproject/public_html/": Permission denied (13)
I have added the following to the /etc/sudoers file:
rsyncuser ALL= NOPASSWD:/usr/bin/rsync
plus I've un-commented:
%wheel ALL=(ALL) NOPASSWD: ALL
I've also tried to run the command with –rsync-path="sudo rsync" as suggested in some posts, but still no luck:
rsync -avz –rsync-path="sudo rsync" files/* sshwheeluser#ip_address:/home/newproject/public_html/
Next I tried to use it with additional -e "ssh":
rsync -avz -e "ssh" –rsync-path="sudo rsync" files/* sshwheeluser#ip_address:/home/newproject/public_html/
which changed the error message (looks like we're getting somewhere):
stdin: is not a tty
sudo: sorry, you must have a tty to run sudo
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at /SourceCache/rsync/rsync-40/rsync/io.c(452) [sender=2.6.9]
This post suggests that require_tty and tty_tickets should be disabled in sudoers, but I can't find these options in the /etc/sudoers file.
I've added (as recommended) Defaults !tty_tickets to the sudoers, but still the same message.
Any idea what else I need to do to make it work?
You should check Selinux logs, rsync is probably been blocked by Selinux.
You can also try to run:
semanage permissive -a rsync_t
Related
I am trying to rsync a local folder to a remote location. This a command that I have run successfully a week ago, but now if i run:
rsync -vrtzu\
--chown=user:webadm
--delete
--exclude-from=.rsyncignore
FOLDER/
USER#REMOTE:/DESTINATION
Then I get the following error message:
zsh:1: no matches found: --usermap=*:USER
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(235) [sender=3.1.3]
make: *** [makefile:39: push] Error 12
The command is run from a makefile, hence the last line.
I am using a regular WSL2 Ubuntu shell, not zsh.
I am able to ssh into the remote location with USER#REMOTE.
I have also checked that both locations have rsync installed (same version).
Finally, there is plenty of disk space available on the remote location.
Any pointers? What should I be checking to improve my diagnostic?
Thanks in advance!
This can happen when the remote shell messes with the command. Not sure exactly why and what it does but it modifies escaping so that the file path becomes invalid.
In your case the shell outputs --usermap=*:USER at log in.
The solution is to change the remote (zsh) shell to bash using the chsh command
I'm pretty sure this is an rsync bug:
zsh:1: no matches found: --usermap=*:USER
It only happens the remote machine's default shell is zsh.
It was fixed somewhere between rsync 3.2.3 (where it's broken) and 3.2.5 (where the bug is gone).
You can verify this by passing -vv to rsync. This prints as one of the first output lines which command invocation rsync is doing on the remote server via SSH.
On a broken version, it prints e.g.:
... ssh ... rsync --server -vvnlogDtpRe.LsfxCIvu "--usermap=*:user" "--groupmap=*:webadm"
On a fixed version, it prints e.g.:
... ssh ... rsync --server -vvnlogDtpRe.LsfxCIvu "--usermap=\*:user" "--groupmap=\*:webadm"
As you can see, they inserted a \ to fix the string being interpreted by zsh.
When rsync is used with jenkins as Execute shell Command on CentOS 6.4, it fails:
[workspace] $ /bin/sh -xe /tmp/hudson3424899639384884888.sh
+ rsync -av /var/lib/jenkins/jobs/myjob/workspace/target/classes/ myuser#myserver.com:/home/myuser/test
rsync: Failed to exec ssh: Permission denied (13)
rsync error: error in IPC code (code 14) at pipe.c(84) [sender=3.0.6]
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in IPC code (code 14) at io.c(600) [sender=3.0.6]
However, it works from the command line:
su jenkins
rsync -av /var/lib/jenkins/jobs/myjob/workspace/target/classes/ myuser#myserver.com:/home/myuser/test
sending incremental file list
sent 17875 bytes received 83 bytes 3990.67 bytes/sec
total size is 1981027 speedup is 110.31
What has to be done to make it work in jenkins as well?
The problem was with SElinux installed on CentOS, which for some reason were blocking ssh for rsync.
Here is a line from /var/log/messages which says the ssh was blocked:
Jun 12 13:45:59 myserver kernel: type=1400 audit(1434109559.911:33346): avc: denied { execute } for pid=11862 comm="rsync" name="ssh" dev=dm-1 ino=11931741 scontext=unconfined_u:system_r:rsync_t:s0 tcontext=system_u:object_r:ssh_exec_t:s0 tclass=file
For now we disabled SElinux on our server, proper solution would be to create custom policy module (1)
I had a similar problem.
In my case jenkins was not executing rsync with the expected user (jenkins) but with another (jboss in my case)
adding 'whoami' to the script and using ssh verbose:
rsync -e "ssh -v" .......
helped to find the problem.
Note, that when you change (add) jenkins user to some group, permission will apply after slave (agent) restart.
I'm trying to alter an Vagrant box I created for my office. Currently, like most boxes, running vagrant ssh logins me in as the vagrant user, but team members get frustrated having to use su - xxadmin to switch to our primary admin user.
In my Vagrantfile, I added: config.ssh.username = "xxadmin", but then I started receiving the common Vagrant error when running vagrant up:
[default] Configuring and enabling network interfaces...
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
sed -e '/^#VAGRANT-BEGIN/,/^#VAGRANT-END/ d' /etc/network/interfaces > /tmp/vagrant-network-interfaces
Stdout from the command:
Stderr from the command:
sudo: no tty present and no askpass program specified
and when running vagrant halt:
[default] Attempting graceful shutdown of VM...
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
shutdown -h now
Stdout from the command:
Stderr from the command:
sudo: no tty present and no askpass program specified
What's going on here? Why would simply changing the ssh user create these errors? How do i find a solution forward?
Specs:
OS X Mavericks (host)
Vagrant 1.3.5
Virtualbox 4.3.2
Debian 7 Wheezy (vm client)
In your box, you need to modify your sudoers file by running visudo and adding the following:
Defaults !requiretty
I kept running into this error until I made sure that my user's NOPASSWD sudoers entry was not being squashed.
I've been hitting a wall with this one and i'm not entirely sure what the issue may be. I will be posting two examples of what i'm trying to do one which works and one which doesn't, unfortunately I need the latter to work.
The Error:
Unexpected local arg: /data/
If arg is a remote file/dir, prefix it with a colon (:).
rsync error: syntax or usage error (code 1) at main.c(1215) [receiver=3.0.6]
This Command executes without issues, however it seems that it does not fully rsync my /data directory.
rsync -e "ssh -e 'none'" --force -azPxvIh --delete-after --exclude-from="/tmp/exclude.txt" root#myserver:/ / > "/tmp/wetrun.txt"
This is the command I've been trying utilize to rsync my /data directory and seems to fail.
rsync -e "ssh -e 'none'" --force -azPxvIh --delete-after --exclude-from="/tmp/exclude.txt" root#myserver:/data/ /data/ > "/tmp/wetrun.txt"
I'm trying to login to a ssh server and to execute something like:
ssh user#domain.com 'sudo echo "foobar"'
Unfortunately I'm getting an error:
sudo: no tty present and no askpass program specified
Google told me to either set the environment variable SSH_ASKPASS or to set askpass in the sudoers file. My remote machine is running on Debian 6 and I've installed the packages ssh-askpass and ssh-askpass-gnome and my sudoers file looks like this:
Defaults env_reset
Defaults askpass=/usr/bin/ssh-askpass
# User privilege specification
root ALL=(ALL) ALL
user ALL=(ALL) ALL
Can someone tell what I'm doing wrong and how to do it better.
There are two ways to get rid of this error message. The easy way is to provide a pseudo terminal for the remote sudo process. You can do this with the option -t:
ssh -t user#domain.com 'sudo echo "foobar"'
Rather than allocating a TTY, or setting a password that can be seen in the command line, do something like this.
Create a shell file that echo's out your password like:
#!/bin/bash
echo "mypassword"
then copy that to the node you want using scp like this:
scp SudoPass.sh somesystem:~/bin
Then when you ssh do the following:
ssh somesystem "export SUDO_ASKPASS=~/bin/SudoPass.sh;sudo -A command -parameter"
Another way is to run sudo -S in order to "Write the prompt to the standard error and read the password from the standard input instead of using the terminal device" (according to man) together with cat:
cat | ssh user#domain.com 'sudo -S echo "foobar"'
Just input the password when being prompted to.
One advantage is that you can redirect the output of the remote command to a file without "[sudo] password for …" in it:
cat | ssh user#domain.com 'sudo -S tar c --one-file-system /' > backup.tar
Defaults askpass=/usr/bin/ssh-askpass
ssh-askpass requires X server, so instead of providing a terminal (via -t, as suggested by nosid), you may forward X connection via -X:
ssh -X user#domain.com 'sudo echo "foobar"'
However, according to current documentation, askpass is set in sudo.conf as Path, not in sudoers.
How about adding this in the sudoers file:
user ALL=(ALL) NOPASSWD: ALL