Generated SSH keypair not working

[ikornaselur]

Struggled a little bit setting FrameOS up.

For reference, I have a Pi Zero set up with the ~5 inch Pimoroni inky screen. I've deployed the controller on a separate server and trying to set the connection up.

I do not have passwords enabled for SSH, so I was happy to see that SSH keypairs are supported in settings. Generating a keypair and adding the public key to .ssh/authorized_keys on the Pi Zero fails to connect because the key doesn't seem to be a valid RSA key

2024-01-03 17:22:09 Deploying frame <name> with build id mkjdapkjexeb
2024-01-03 17:22:09 Connecting via SSH to <user>@192.168.86.45 (keypair)
2024-01-03 17:22:09 not a valid RSA private key file

I tried creating my own SSH keys (using ed25519) and saving that directly in settings, which gives me a different error

2024-01-03 17:21:02 Deploying frame <name> with build id tqfnsxmojkfk
2024-01-03 17:21:02 Connecting via SSH to <user>@192.168.86.45 (keypair)
2024-01-03 17:21:02 unpack requires a buffer of 4 bytes

I then finally created a RSA keypair with ssh-keygen -t rsa and was able to get that working. If the generated SSH keypairs work on your end, then I'm happy to provide any further information for troubleshooting.

[mariusandra]

Hey @ikornaselur , thanks for trying out FrameOS and for reporting back!

Indeed, currently only RSA keys are supported. It doesn't seem too hard to add ed25519 though. I'll see what can't be done, but can't promise exactly when I'll get to it.

[ikornaselur]

No worries! I think it's fair that only RSA keys are supported. But the main issue is still that the generated keypair from the UI, with this button:

produces the "not a valid RSA private key file" error, so seemingly the key being generated by FrameOS is invalid. I was only able to get a manually generated keypair working.

Does a generated keypair from the UI work on your end? I'm happy to investigate further on my end and see if I can identify the issue.

Oh, and for further reference, I am deploying the controller with docker and the :latest tag

[sowbug]

Same here. Also docker with latest tag. Just to repeat -- the issue isn't ed25519 support, it's that the UI's own self-generated RSA keys don't work out of the box.

For those who aren't familiar with Linux and are just trying to get it working, do this:

• ssh to the rpi
• ssh-keygen -t rsa and when it asks for where to save and which passphrase to use, hit enter
• cd .ssh/
• cat id_rsa.pub >> authorized_keys
• chmod 400 authorized_keys

Now cat id_rsa and copy the output. Then go back to the controller's UI (http://yourserver:8989/settings) and paste the output into the private-key field. Do the same with id_rsa.pub, but in the public key field. Save settings, and then go to your frame's redeploy action, and it should work (in my case it didn't, but I'll enter a new issue).

[mariusandra]

This should work now!

I tried changing the default key from RSA to ed25519, but ran into some weird issue. The generated key seemed much too short, even for ed25519, and ChatGPT seems to think it's better to defer to ssh-keygen than use python with ed25519. So for another day.

[alexrudd2]

Strange, I thought this was fixed by #27 but it recurred with me again, running ac2e102.

Working around for now since I want to (1) test #30 again and (2) try out the dithering on a red/black/white InkyWhat. (I had code lying around locally that tried to dither with Pillow but never quite worked)

False alarm.