RSync failing after the first upload

[Tom Mitchell]

Hello,

weewx 3.8.2 running in a Docker container. Connecting the the database just fine and using the Simulator. I have rsync configured to upload to a cloud host.

First time through, the report upload works fine:

weewx[9]: reportengine: Running report RSYNC

weewx[9]: reportengine: Found configuration file /home/weewx/skins/Rsync/skin.conf for report RSYNC

weewx[9]: manager: Added record 2019-04-06 16:05:17 EDT (1554581117) to database 'weewx_local'

LOOP:   2019-04-06 16:05:17 EDT (1554581117) altimeter: 32.3940721833, appTemp: 28.369127419, barometer: 32.3429914465, cloudbase: 1295.87222115, dateTime: 1554581117, dewpoint: 27.1243263624, heatindex: 32.5973641355, humidex: 32.5973641355, inDewpoint: 31.0794006064, inHumidity: 29.999657861, inTemp: 63.0001710695, maxSolarRad: 495.258619499, outHumidity: 79.9997433946, outTemp: 32.5973641355, pressure: 32.3429914465, radiation: 230.36959363, rain: 0, rainRate: 0, usUnits: 1, UV: 3.22517431082, windchill: 32.5973641355, windDir: 359.998460368, windGust: 5.13210704991e-05, windGustDir: 359.998460368, windSpeed: 4.27675587487e-05

weewx[9]: rsyncupload: rsync'd 160 files (271,814 bytes) in 2.10 seconds

But on the subsequent passes, it acts like it doesn't recognize the upload host:

weewx[9]: reportengine: Running report RSYNC

weewx[9]: reportengine: Found configuration file /home/weewx/skins/Rsync/skin.conf for report RSYNC

The authenticity of host 'foo.bar.com (a.b.c.d)' can't be established.

ECDSA key fingerprint is a8:17:90:cd:08:5d:3f:84:8d:b3:9d:91:3d:e0:e2:68.

Are you sure you want to continue connecting (yes/no)? weewx[9]: manager: Added record 2019-04-06 16:10:17 EDT (1554581417) to database 'weewx_local'

LOOP:   2019-04-06 16:10:17 EDT (1554581417) altimeter: 32.3939674154, appTemp: 28.1327127704, barometer: 32.3428868355, cloudbase: 1294.87161178, dateTime: 1554581417, dewpoint: 26.9178545608, heatindex: 32.3864896527, humidex: 32.38648965

I do have a known_hosts file in /home/weewx/.ssh

I am able to ssh in as the username configured in weewx without being prompted.

[[RSYNC]]

# rsync'ing to a webserver is treated as just another report

skin = Rsync

# If you wish to use rsync, you must configure passwordless ssh using

# public/private key authentication from the user account that weewx

# runs as to the user account on the remote machine where the files

# will be copied.

#

# The following three lines determine where files will be sent.

server = foo.bar.com

path = /home/tom/html/local/

user = tom

# Rsync can be configured to remove files from the remote server if

# they don't exist under HTML_ROOT locally. USE WITH CAUTION: if you

# make a mistake in the remote path, you could could unintentionally

# cause unrelated files to be deleted. Set to 1 to enable remote file

# deletion, zero to allow files to accumulate remotely.

delete = 0

Curious of anyone has ever seen this before.

Thanks in advance.

[gjr80]

Hi,

Certainly seen the same message before but can't say it was under the same circumstances though. No ssh/rsync expert but just thinking aloud as to what you could do; have you tried running rsync (repeatedly) from the command line with the same credentials so you can see/deal with anything it throws up? Have you tried removing the cached key for foo.bar.com with:

$ ssh-keygen -R 192.168.1.123

Gary

[Tom Mitchell]

Thanks @gary for the followup. I turned off stricthostkeychecking in the .ssh/config file which resolved it. I don't know exactly this cloud server does this, but it works and I am not going to dig too deep on it.

Thanks again.

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/qbvL3PX1vDg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gjr80]

Well you're way ahead of me. Main thing is it works.

Gary

To unsubscribe from this group and all its topics, send an email to weewx...@googlegroups.com.

[vince]

On Tuesday, April 9, 2019 at 1:57:25 AM UTC-7, Tom Mitchell wrote:

Thanks @gary for the followup. I turned off stricthostkeychecking in the .ssh/config file which resolved it. I don't know exactly this cloud server does this, but it works and I am not going to dig too deep on it.

That's usually a really bad idea.  Strict host checking tries to make sure that you're not connecting to an imposter computer using the same ip address as the one you're trying to connect to.   What rsync is doing is saying "hey - I don't know who that remote system is, is this ok?" and asking for verification.   Very normal ssh behavior.

If you're building a docker container to run weewx, you could have your container build proces create its ~/.ssh/known_hosts file with the host key for the system you typically connect to, if you have stable host keys on the system you're rsync'ing to (which is usually the case).  That's a far more secure way of doing things.

[Tom Mitchell]

Thanks for the advice. What happens is gcp appends a new entry to my known_hosts file (which already has the hostname and key I use) with a very strange looking one, and then fails to connect after doing it once successfully. I am happy to get it right, but at this point, I just don't understand the rewrite and subsequent behavior.

[vince]

On Tuesday, April 9, 2019 at 7:50:17 AM UTC-7, Tom Mitchell wrote:

Thanks for the advice. What happens is gcp appends a new entry to my known_hosts file (which already has the hostname and key I use) with a very strange looking one, and then fails to connect after doing it once successfully. I am happy to get it right, but at this point, I just don't understand the rewrite and subsequent behavior.

Yes - with strict host checking off, you'll get an additional line added automatically.   Normally it prompts.  This is ssh-101 (and admittedly a little annoying in some circumstances when you try to automate things).     The known_hosts file containes the 'remote' computer(s) host key(s), not your account's key, not your 'local' computer or container's host key.

[Tom Mitchell]

Thanks, Vince.

--