SSH Access - Upload SSH public-key - Access denied

[imbaSD]

at 20:09 was pressed the save button and immediately open the log page

whatever, as far i found solution its ok
just wanted to inform in case of similar issue in future

[teki4u]

That's not the full log.

I'm not able to solve this for you sorry.
Unless someone else can demonstrate they also get the error, and can show me a way to reproduce it 100% of the time, it's just not possible for me to guess a fix.

Hi!, i had the same issue as OP in latest 1.13.0.x gargoyle-ispy 2021-August-15 20 build and i tried many times with logread, but really there is nothing else relevant than the 3 consecutive dropbear logs in the picture below, only the port number changed everytime.
The only quick proof i could think of at the moment to show that the connection refused and not succeeded using ssh keys is with putty event log.

As you can see Putty Event Log shows "Server refused our key", then "Sent password" (so i could login that way) and few seconds later logread shows "dropbear : Password auth succeeded for 'root'".

And here is how it is displayed in the WebUI:

Code: Select all

AAAAB... H+pw      is the one i manually copied in /etc/dropbear/authorized_keys
BEGIN... N                    is the ssh public-key file uploaded from the WebUI

I generated a pair of SSH keys with PuTTYgen for testing purposes: SSH-2 RSA 4096 bits


Let me know if you need anything else to try solve this problem.

[RomanHK]

It may be a useless question but: can you try restarting the dropbear daemon? it will help?

Code: Select all

/etc/init.d/dropbear restart

[teki4u]

It may be a useless question but: can you try restarting the dropbear daemon? it will help?

Code: Select all

/etc/init.d/dropbear restart

Nope, same thing. The SSH key is added as BEGIN... N within Authorized Keys section.
I ran the command before adding the key file and after saving changes.

[Lantis]

Issue 1, Gargoyle is not handling the input file correctly.
Issue 2, Dropbear only handles the openssh style public key, not the style people in this thread are using.

Issue 1, not worth fixing IMO. We could try doing some fancy manipulation of the file and reformat it, but lets just get the input correct in the first place.

From this screenshot (https://i.postimg.cc/wBbW4mpT/Anotaci-n ... 142236.png), take the contents of the box which says "Public key for pasting into OpenSSH authorised_keys file" and create a new file containing only that.
Upload this via the GUI and it should be fine.

[teki4u]

From this screenshot (https://i.postimg.cc/wBbW4mpT/Anotaci-n ... 142236.png), take the contents of the box which says "Public key for pasting into OpenSSH authorised_keys file" and create a new file containing only that.
Upload this via the GUI and it should be fine.

That did the trick, thanks!. Faster than manually logging via ssh just to paste the openssh public key using 'vi' text editor, while setting up the router from the WebUI.

Note: it works with and without extension eg. txt when saving the new file containing the public key (OpenSSH) provided by PuTTYgen.

Would it be possible to update the Info about SSH Access to mention that for Windows / Putty users?

[valinor]

Hey guys

Having a similar problem with ssh keys uploading.
Actually, I found three problems - two incorrect validations and one looking like a bug in some generated script

1: (not critical) if a key you're trying to upload contains no name (the rest of the string after the base64 encoded text) or a name with spaces, and you haven't specified one in the appropriate input field, the UI gives a misleading error "Invalid key. Please ensure that file contains a valid SSH public-key and try again"

2: (not critical) However, I was able to add (at least in the UI screen) ed25519 keys, and there was no error, despite ed25519 isn't supported by dropbear so far

3: (critical) when I pressed the "Save changes" button, the existing /etc/dropbear/authorized_keys file was deleted and nothing more happened. There was no error in the console but one in the router's log:
root@gw:~# logread -f

Code: Select all

Sat Aug 28 02:52:56 2021 daemon.err uhttpd[6611]: /tmp/tmp[.]sh: line 7: syntax error: unterminated quoted string

(I was forced to enclose the dot into square brackets because PHPBB thinks it was an URL and it denies me to post URLs (??))

One else thing. When an authorization session is expired, the "save" button does not work correctly. There is a redirection to the login page in the network log, and nothing happens in the UI

P.S. I have Archer C7 v4.0 and Gargoyle 1.12.0

[Lantis]

I'll take a look at these issues when i get a chance. i have not forgotten about them

[Lantis]

Would it be possible to update the Info about SSH Access to mention that for Windows / Putty users?

I've added a hint to the text.

1: (not critical) if a key you're trying to upload contains no name (the rest of the string after the base64 encoded text) or a name with spaces, and you haven't specified one in the appropriate input field, the UI gives a misleading error "Invalid key. Please ensure that file contains a valid SSH public-key and try again"

Noted. A little misleading but i think it is more effort than it is worth to have 2 different error messages. For now we will live with this one unless someone submits a patch to do otherwise.

2: (not critical) However, I was able to add (at least in the UI screen) ed25519 keys, and there was no error, despite ed25519 isn't supported by dropbear so far

The hint text above the field suggests generating an RSA key. I think we'll leave this one down to natural selection.
In future (1.15.x) ed25519 will be supported anyway (for most devices).

3: (critical) when I pressed the "Save changes" button, the existing /etc/dropbear/authorized_keys file was deleted and nothing more happened. There was no error in the console but one in the router's log:

This was due to the nameless key format not being sanitised correctly. I've fixed this with https://github.com/ericpaulbishop/gargo ... 6b241e78c0.
At this stage i don't intend to backport it to 1.12.x.

One else thing. When an authorization session is expired, the "save" button does not work correctly. There is a redirection to the login page in the network log, and nothing happens in the UI

Noted. I've had a quick look into if this is easy to fix and it isn't. I think instead of a redirect it needs to force a 401 unauthorised and the client pushes itself back to login.sh instead of via a 302.
I'll keep it in mind for a future enhancement.

Thanks all.