The problem is not with stunnel, but with rsyncd. I assume you are running rsyncd on the source machine in conjunction with the /etc/rsyncd.conf file. The cool thing about running rsyncd through stunnel is the rsync client appears to the rsyncd as a local machine (obviously) so permissions are a problem. The best way I could recommend since you need to access root owned files would be to setup your rsyncd entry something like:
## Example of full access to /home directory [home] uid = root gid = root path = /home comment = home directory. hosts allow = 127.0.0.1 read only = no ignore nonreadable = no refuse options = checksum dont compress = *
If you notice the "hosts allow" directive only allows access from localhost(127.0.0.1). The problem is *anyone* can connect to your stunnel server unless you require security I would recommend using your firewall to allow access to your stunnel instance and also to use non-standard ports (I.E. 50000-50010). Using a firewall in lieu of authentication is obviously NOT secure or even recommended for a production environment but is simply added security that certainly doesn't hurt. The workaround would be to secure stunnel and leave rsyncd wide-open to localhost.
As for the "connection reset" errors I was getting the same thing until I upgraded to the latest version of stunnel. I read a post on stunnel.mirt.net about it. Are you sure you're using the latest version of stunnel?
Jeremy
-----Original Message----- From: Gabe Martin-Dempesy [mailto:gabe@mudbugmedia.com] Sent: Tuesday, January 03, 2006 1:49 PM To: stunnel-users@mirt.net Subject: [stunnel-users] Connection reset by peer on same local network?
I'm attempting to setup an encrypted rsync to pull backups off of a file server onto a safe backup machine. To do this I'm using a combination of stunnel and rsyncd (It needs to pull root-owned files, so -e ssh wouldn't work unless I want to have a backup script remotely logging in as root!!) For now the machines are both on the same local network, 10.10.10.0/24, but I'm have weird problems with stunnel getting a 'connection reset by peer' after a couple minutes of the rsync, halting the transfer prematurely. Here's what I see in the logs:
Client: Dec 29 10:19:21 backup stunnel[2568]: 8001 connected from 127.0.0.1:39215 Dec 29 10:21:09 backup stunnel[2568]: SSL_write: Connection reset by peer (104) Dec 29 10:21:09 backup stunnel[2568]: Connection reset: 192532 bytes sent to SSL, 5920666 bytes sent to socket
Server: Dec 29 10:20:00 proto stunnel[30434]: 973 connected from 10.10.10.20:54054 Dec 29 10:20:00 proto rsyncd[1776]: rsync on xserve from localhost (127.0.0.1) Dec 29 10:21:49 proto stunnel[30434]: SSL socket closed with 16384 byte(s) in buffer Dec 29 10:21:49 proto stunnel[30434]: Connection reset: 5953434 bytes sent to SSL, 98416 bytes sent to socket Dec 29 16:21:49 proto rsyncd[1776]: rsync: writefd_unbuffered failed to write 4096 bytes: phase "unknown": Connection reset by peer Dec 29 16:21:49 proto rsyncd[1776]: rsync error: error in rsync protocol data stream (code 12) at io.c(666)
Note that the client gets the 'connection reset by peer' a good 40 seconds before the server notices the disconnect.
Here are the associated stunnel.conf's, which are pretty basic Client: cert = /etc/stunnel/backup.crt key = /etc/stunnel/backup.key setuid = stunnel setgid = stunnel pid = /var/run/stunnel/stunnel.pid socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 client = yes [8001] accept = 8001 connect = 10.10.10.15:973
Server: cert = /etc/stunnel/proto.crt key = /etc/stunnel/proto.key setuid = stunnel setgid = stunnel pid = /var/run/stunnel/stunnel.pid socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 [973] accept = 973 connect = 127.0.0.1:rsync
Both are using: stunnel 4.09 on i686-pc-linux-gnu PTHREAD+POLL+IPv6+LIBWRAP with OpenSSL 0.9.7e 25 Oct 2004 Global options cert = /etc/stunnel/stunnel.pem ciphers = ALL:!ADH:+RC4:@STRENGTH debug = 5 key = /etc/stunnel/stunnel.pem pid = /var/lib/run/stunnel.pid RNDbytes = 64 RNDfile = /dev/urandom RNDoverwrite = yes session = 300 seconds verify = none Service-level options TIMEOUTbusy = 300 seconds TIMEOUTclose = 60 seconds TIMEOUTconnect = 10 seconds TIMEOUTidle = 43200 seconds
Both of these machines are Gentoo 2005.1, updated to current, using the hardened 2.6 profile. Neither of them use non-standard make flags.
Does anyone have some insight? There shouldn't be any "peer" (besides themselves) in the way between these two boxes to disconnect them.
_______________________________________________ stunnel-users mailing list stunnel-users@mirt.net http://stunnel.mirt.net/mailman/listinfo/stunnel-users