No PEM-encoded private key found #1892
Comments
github-actions
bot
added
the
triage
|
Hmm, strange. Can you check whether you have a It should look vaguely like this, $ ls -ld ~/.config/gsconnect; ls -l ~/.config/gsconnect
drwxr-xr-x. 2 ferd ferd 4.1k Sep 25 2020 /home/ferd/.config/gsconnect
total 21k
-rw-------. 1 ferd ferd 1.2k Nov 19 2017 certificate.pem
-rw-------. 1 ferd ferd 1.9k Jun 25 2020 id-gsconnect
-rw-------. 1 ferd ferd 1.2k Sep 25 2020 id-gsconnect-cert.pub
-rwx------. 1 ferd ferd 391 Jun 25 2020 id-gsconnect.pub
-rw-------. 1 ferd ferd 1.8k Nov 19 2017 private.pemOne of the only things I can think of that might cause this is if the config directory is accidentally owned by The error GSConnect logged shows it's dying at line 370 of openssl req -new -x509 -sha256 \
-out $HOME/.config/gsconnect/certificate.pem \
-newkey rsa:4096 -nodes \
-keyout $HOME/.config/gsconnect/private.pem \
-days 3650 \
-subj '/O=andyholmes.github.io/OU=GSConnect/CN=$RANDOM_UUID_STRING'...and then checks that the So, if openssl couldn't create the files, that would be a problem that could manifest this way. (You can also try running that command yourself — just insert anything for If you do, then that's why GSConnect failed as well. If you don't, then the files should be there and usable by GSConnect as well, so win/win.) |
ferdnyc
added
needs info
|
Hello, I am so sorry for late reply. This directory indeed exists, and it has read-write permissions: And well, I run this command you've written, and in terminal it does successfuly execute (it outputs some kind of '.' and '+' string; as far as I understand, it's some kind of a private image?). What I am concerned about, is that I have only two files here... |
|
Well, problem solved. I have reinstalled the extension (it's the same version) from Fedora's repository... I don't know what was the problem earlier. Thank you for help though! I won't close the issue now, in case if someone would like to investigate it further. |
ferdnyc
added
bug
The interesting thing there, though, is the SIZE of those files: They're both empty. So, something clearly went wrong when generating them originally. I'd probably have suggested deleting them and letting them be re-created (although if you ran the
That, I wouldn't worry about. The other files are for the SSH connectivity used by the file-sharing plugin, if you haven't mounted a shared directory yet then it makes sense you wouldn't have those. (They definitely wouldn't be created until your two devices could at least communicate.)
Thanks, yeah normally I'd say that if a reinstall fixed it, then that's good enough and there isn't much we can do... but if the original problem was that there were existing, empty credential files that were blocking the creation of valid ones, and that was enough to prevent GSConnect from establishing connectivity with other devices, then that's something we probably can try to detect, and to handle more intelligently. |
Describe the bug
On launch, the extension throws an error below. This prevents a user from connecting to any devices in the network. OpenSSL is installed and is working correctly.
Steps to reproduce
Expected behavior
No errors, easy connection.
GSConnect version
58
Installed from
GNOME Extensions website
GNOME Shell version
47
Linux distribution/release
Fedora 41
Paired device(s)
Iphone SE 2 (cannot pair)
KDE Connect app version
0.4.1 (1)
Plugin(s)
No response
Support log
Screenshots
Notes
No response
The text was updated successfully, but these errors were encountered: