rsync problem after ssh upgrade - openssh
This is a discussion on rsync problem after ssh upgrade - openssh ; Hello.
In my setup I collected logs from many hosts using ssh + rsync. It
worked fine untill I upgraded OpenSSH from version 5.0p1 to 5.1p1 on those
hosts running Slackware Linux. After upgrade nothing works as before. When
I ...
-
rsync problem after ssh upgrade
Hello.
In my setup I collected logs from many hosts using ssh + rsync. It
worked fine untill I upgraded OpenSSH from version 5.0p1 to 5.1p1 on those
hosts running Slackware Linux. After upgrade nothing works as before. When
I try to get logs connection breaks with the following message in syslog
on the server side:
Aug 4 15:34:44 srvhost sshd[8130]: Accepted publickey for user from 192.168.1.30 port 48421 ssh2
Aug 4 15:34:44 srvhost rsyncd[8136]: rsyncd version 2.6.9 starting, listening on port 873
Aug 4 15:34:44 srvhost rsyncd[8136]: bind() failed: Permission denied (address-family 2)
Aug 4 15:34:44 srvhost rsyncd[8136]: socket(10,1,6) failed: Address family not supported by protocol
Aug 4 15:34:44 srvhost rsyncd[8136]: unable to bind any inbound sockets on port 873
Aug 4 15:34:44 srvhost rsyncd[8136]: rsync error: error in socket IO (code 10) at socket.c(477) [receiver=2.6.9]
I see that port 873 is privileged and rsyncd can't bind to it. But it
could before upgrade! I tried to bind rsyncd to unprivileged port. It
works but not as expected. rsyncd starts in background, connection to
it through ssh doesn't occur and it continues to run in the background
even when I close ssh connection.
What the reason of such changed behaviour? How can I restore to what I
have before?
authorized_keys on server:
command="rsync --daemon --config=/home/user/.ssh/rsyncd.conf",no-pty ssh-rsa AAAAB3Nz.......
rsyncd.conf on server:
[logs]
path = /home/user/log
use chroot = false
read only = true
Server sshd_config:
Port 12345
AddressFamily inet
Protocol 2
DenyUsers baduser
UseDNS no
Subsystem sftp /usr/libexec/sftp-server
On client side a script uses this line to get logs:
rsync -v -e "ssh -q -T -p 12345 -l user -i ./key_logs_collector -o
'BatchMode yes' -o 'ConnectTimeout 30' -o 'StrictHostKeyChecking no' -o
'CheckHostIP no'" -zqt --max-size=100M srvhost::logs/* logs/
---
Alexander Pravdin
aledin@evpatoria.com.ua
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/li...enssh-unix-dev
-
Re: rsync problem after ssh upgrade
On Tue, 05 Aug 2008, Alexander wrote:
> Aug 4 15:34:44 srvhost sshd[8130]: Accepted publickey for user from 192.168.1.30 port 48421 ssh2
> Aug 4 15:34:44 srvhost rsyncd[8136]: rsyncd version 2.6.9 starting, listening on port 873
> Aug 4 15:34:44 srvhost rsyncd[8136]: bind() failed: Permission denied (address-family 2)
[...]
> authorized_keys on server:
>
> command="rsync --daemon --config=/home/user/.ssh/rsyncd.conf",no-pty ssh-rsa AAAAB3Nz.......
"rsync --daemon" is documented as having a different behaviour depending
on whether or not stdin is a socket. I guess that, with the old sshd,
rsync received a socket as stdin, but with the new sshd it receives
somethign else (perhaps a pipe or a tty).
I suggest that you read the part of the rsync man page under "USING
RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL CONNECTION", and then change
the way you attempt to invoke rsync, so that you do not rely on
something so fragile as whether or not sshd used a socket for rsync's
stdin.
Alternatively, you could patch rsync to have a new command line option
that makes it behave the way you want regardless of whether or not its
input is a socket.
--apb (Alan Barrett)
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/li...enssh-unix-dev
-
Re: rsync problem after ssh upgrade
On Tue, Aug 05, 2008 at 12:35:03PM +0200, Alan Barrett wrote:
> > command="rsync --daemon --config=/home/user/.ssh/rsyncd.conf",no-pty ssh-rsa AAAAB3Nz.......
>
> "rsync --daemon" is documented as having a different behaviour depending
> on whether or not stdin is a socket. I guess that, with the old sshd,
> rsync received a socket as stdin, but with the new sshd it receives
> somethign else (perhaps a pipe or a tty).
yes, used to be a socketpair, not it's a pipe (like in the early days).
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/li...enssh-unix-dev
