Pre-shared Private Key file for SFTP

[radilly]

I was interested in trying the SFTP option. I'm a little uncertain what the "Pre-shared Private Key file for SFTP" field is for?

Let me explain a little. I've used ssh for many years for remote logins and issuing remote commands. I also use scp routinely, and I've used it in some Python scripts running on Raspberry Pis. For hosts I connect to regularly I use a public/private rsa key pair - https://www.ssh.com/ssh/keygen/ so no password needs to be provided. In my Python I've used both SCP and FTP, but a password needs to be stored for the latter which I'd rather avoid. From the command line (and under Python) I can issue scp and sftp commands without passwords (or any reference to a key file).

Is that file optional if one has a configured and working public/private rsa key pair?

Appreciate any help!
Thanks,
Bob

[radilly]

Oh ... I'm aware of https://cumuluswiki.org/a/SFTP but that page was last updated 11 May 2017. It looks like the SFTP option is very recent.

[freddie]

I was interested in trying the SFTP option. I'm a little uncertain what the "Pre-shared Private Key file for SFTP" field is for?

Isn't it the path to your private key? MX requires your private key to encrypt your data before transmission. You will have uploaded your public key to the remote host in order to have the host decrypt the data

[mcrossley]

@freddie - correct, it needs to be the path to your private key file. Cumulus MX will not look for the key in any key stores you may have defined.

[radilly]

Cumulus MX will not look for the key in any key stores you may have defined.

Cryptography is a topic I'm pretty ignorant of frankly. The terminology is a little unfamiliar, but it may be because I am focused on a Unix perspective. For Windows I use PuTTY and WinSCP which leverages it's key management via Pagent.

The default private key location for ssh-keygen on Linux is /home/pi/.ssh/id_rsa and a passphrase on it is recommended. With that configured, and id_rsa.pub added to authorized_keys on the remote server, I can issue ssh, scp and sftp on the command line without supplying a password. It was my understanding that only the public key (id_rsa.pub) should be shared and the private key kept ... well ... private.

At the end of the day my goal has been not to never store a password in clear text for any application. For ftp a long, long time ago we'd use a ~/.netrc which stored passwords in clear text but abandoned it in favor of ssh. Granting access to the private key seems like a similar exposure, no?

Thanks,
Bob

Oh, one place I use password-less scp to move files to a remote server (on my hosted site) is for the images on https://dilly.family/wx/webcam.html.

[mcrossley]

Well, you keep the private key private to you (the client), and give the public key to the services you wish to log in to. Giving out your private key to all the other servers you wish to access would be insecure.

In the end afaik they are just a pair of symmetric keys, it doesn't matter which one you call private or public so long as you use them consistently.

But what you are saying is completely consistent with my description isn't it?

Your private key is kept in your user profile, and you give the public key to the remote services.
You do the same with Cumulus, give it the same private key because it is representing you, and add your public key to the SSH service.
If you were connecting FROM the rpi it would use the private key in your local store, but if you want to connect using that user account from another computer you have to copy the private key there as well.

[radilly]

I did take a stab at this but not sure I got the right combination of fields filled in appropriately. I tried a couple of things, but ran into a snag. I host through Namecheap and have found that they seem to have some controls in place to protect websites and servers. My virtual server went down, so I chatted with a CSR and they told me "the IP was blocked due to brute force attempts". They reset it - but I decided not to mess with it any more. FTP is getting the job done.

I have thought about pointing CMX to another Pi on my subnet for testing (I did a lot of testing during my career and I don't give up easily ). I confess that I am having a little trouble seeing how the fields in this section work together to handle FTP or SFTP (where I tend to use SCP in my code).

In case it's useful to others, I also am (literally) watching which files get updated (on Raspbian) in real time using:

Code: Select all

watch "find . -mmin -10 -print | xargs ls --full-time -tld"

That tracks files modified over the past 10 minutes and sorts by modification time (every 2 seconds). As far as I can see, logging notwithstanding, the only 2 parameters affecting the timing of updates are "Upload interval" and "Realtime interval" (and the matching user exits Program and Realtime program).

I know I could leverage "Internet settings" --> "External programs" to run some Python code invoking scp or even rsync** (over ssh) to do a password-less upload using the keygen method. I already have code doing that for web cam images.

Cheers, and Thanks!
Bob

** rsych is pretty efficient and could synchronize directories (web) without being told which files to upload explicitly. The downside is you'd end up with files on the server which aren't really necessary. It looks like realtime.txt is an exception by not being in /web. If I come up with anything interesting I'll share it...