Cumulus Support

I installed Cumulus MX 3.22.2 (build 3213) today on ubuntu on a Raspberry Pi 4.

I setup a connection to an Amazon Lightsail instance running Ubuntu. I can connect with ssh/sftp/scp using the pem key and upload files to the /var/www/html/weather directory just fine.

I'm running Cumulus MX as root on the PI and connecting to the ubuntu user on the Lightsail instance.

When connecting via CumulusMX though I get the following:

2022-10-24 17:09:38.705 RealtimeReconnect: Realtime ftp attempting disconnect
2022-10-24 17:09:38.706 RealtimeReconnect: Realtime ftp disconnected
2022-10-24 17:09:38.706 RealtimeReconnect: Realtime ftp attempting to reconnect
2022-10-24 17:09:39.062 RealtimeReconnect: Realtime ftp attempting to reinitialise the connection
2022-10-24 17:09:39.062 RealtimeSSHLogin: Attempting realtime SFTP connect to host xx.xxx.xxx.xxx on port 22
2022-10-24 17:09:39.397 RealtimeSSHLogin: Error connecting SFTP - Permission denied (publickey).
2022-10-24 17:09:39.397 RealtimeReconnect: Realtime ftp connection failed to connect after reinitialisation
2022-10-24 17:09:39.397 RealtimeReconnect: Sleeping for 20 seconds before trying again...

I've checked the /root/.ssh/known_host file on the PI and ensure the authorized_key file on ubuntu has the key.

Any ideas?

Thanks
Mike

Have you told MX where to find your private key in order to perform encryption? Under Settings -> Internet Settings, tick Enable FTP Connections, then select SFTP protocol, then the pre-shared key authentication method, which gives you a box to enter the path to the private key file. Note that MX doesn't use system SSH, it has its own.

Thank you for the response.

I placed the private key in the CumulusMX directory and pointed to it during the setup. It is the same key I've used with the command line ssh/sftp/scp commands.

Mike

Check your file permissions on the copied key file, can the user CMX is running under read it?
Same for the server public key.

I had to convert to PEM RSA private key for CMX

I'm double-checking the permissions and started looking at the PEM RSA, I think that might be the issue as the openssh keys have not worked to this point.

Thanks Rogerthn for the tip and I'll see how it works.

Mike

OK Mike
My commands below

For reference...

SSH.NET supports the following private key formats:

• RSA in OpenSSL PEM and ssh.com format
• DSA in OpenSSL PEM and ssh.com format
• ECDSA 256/384/521 in OpenSSL PEM format
• ECDSA 256/384/521, ED25519 and RSA in OpenSSH key format

Private keys can be encrypted using one of the following cipher methods:

• DES-EDE3-CBC
• DES-EDE3-CFB
• DES-CBC
• AES-128-CBC
• AES-192-CBC
• AES-256-CBC

Finally got some time to work through this, but still no luck.

For some reason, I can connect via the pem key with the command line ssh on a Mac and using SecureCRT without issue.

I've checked the authorized_keys files permissions and ensured the public key is in place. I also checked the private key permissions are correct. I even did a snapshot of the AWS Lightsail instance and recreated the instance with a new default key. I also create several new keys, but each time, I get

2022-10-31 15:20:40.042 RealtimeSSHLogin: Attempting realtime SFTP connect to host xx.xxx.xx.xxx on port 22
2022-10-31 15:20:41.320 RealtimeSSHLogin: Error connecting SFTP - Permission denied (publickey).
2022-10-31 15:20:41.329 Starting Realtime timer, interval = 30 seconds

Is there a debug flag for sftp to get more details? Any other sftp authentications methods that might work? I guess I could try a password but that is not as secure.

Thanks
Mike

Solved the problem.

I'm running Ubuntu 22.04, and there is an issue with ssh-rsa SHA1 hash algorithm being deprecated. Seems like some programs ignore the issue but ssh.Net does not.

In /var/log/auth.log I found: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth] and Google this message which lead me to https://askubuntu.com/questions/1409105 ... from-20-04

I did not change the keys, but instead added the following to /etc/ssh/sshd_config
And restarted sshd Lesson relearned, do not just check the initiating endpoint, but check the other endpoint as well.

Thanks for the help.

Mike