Hi all,
I need help.
I have a running openWRT, can log in as root with password,
login per ssh with password is on, login as root per ssh with password is on but 'ssh root@Router-IP' does not work.
The password of root is queried but the password with which I log in as root on the interface is not accepted.
You know what the cause here can be.
I remember that at the very beginning of the installation a password was queried at the first contact and then was never brought back .....????
Thanks fanifeey
What are the contents of /etc/config/dropbear ?
1 Like
How should I check this without a console?
Good question! I realise I slightly misread your original post. I thought your problem was that "ssh x.x.x.x" presented you with a login challenge which you were able to pass successfully, but "ssh root@x.x.x.x" was causing problems. Apologies for the misunderstanding.
I can think of a couple of possible approaches:
- Change the password in the admin web page; the password is the same for web management and SSH management.
- Implement SSH keys for authentication; the public key can be pasted in the web admin page.
Can't guarantee that either of those options will fix SSH authentication, depending on what's gone wrong behind the scenes. Can't hurt to try, though.
2 Likes
Changing the password doesn't help!
I inserted a rsa-pub-key with coppy and paste in 'asministration/ssh-keys from the PC from the /etc/ssh. nor does he recognize them.
Can it be that something is missing in the software installation?
ICh also installed the bash under software. Why can't I access them from the admin website? Why can you install this at all if it is not usable?
Greeting
This might be an oddball question, but bear with me.
Does your password contain any of the following characters? " @ £ # | \ ~
Alternately, does your password contain any other characters which might move around the keyboard depending on which keyboard layout you might use?
2 Likes
- Why didn't you install it in the web GUI?
- I'm assuming you tried this before your were locked out on command line?
And you're sure you didn't disable Allow root logins with password???Did you try logging in with the key???
At this point, I'd advise resetting to defaults...I recall some threads like this...I've even had the issue in the past...I simply reset to defaults and started over.
1 Like
Yes, I use the # and * and ! .
Welcome to Linux. I don't advise use of Exclamation Marks in Linux - except where scripting, commands and programs state.
3 Likes
From long, bitter experience of having to juggle US and UK keyboard layouts at work, I've made the choice to avoid certain characters in my passwords. # is one of those characters I no longer use. I'm not going to tell you that character is definitely the cause of your problem (it sounds like there might be other stuff going on) but if there's any chance there might be some character translation going on then it might be an explanation of it.
2 Likes
As a quick test, I spun up an x64 VM for OpenWRT 19.07.5, to see what it might do.
As expected, I got the usual "You don't have a password set" warning when I first signed in. So I set a password on the admin web page, and then went about trying to connect via SSH.
Here's the SSH configuration:
Here's what I see if I try to connect via SSH:
And after I type the password...
Then I saved an SSH public key in the GUI:
And now I don't get a password prompt; I sign straight in thanks to the SSH key agent running in the background:
1 Like
And what about + and , and - ?
Well, yes, this is because the key is saved [in PuTTY].
A Linux command may look like:
ssh -i /home/fanifeey/Documents/fanifeey_key/foo.key root@192.168.1.1
- What about your key that's not working?
- Also:
2 Likes
I'm aware; I was offering it as an illustration for what the OP might broadly expect to see if the public key had in fact been saved correctly in the GUI (which would have populated /etc/dropbear/authorized_keys behind the scenes). The point being, even if the OP's password is encountering suspected keyboard translation issues, public key auth ought to still work and provide a way into the command line.
2 Likes
It cannot be because of the special characters or the password length.
I have now tried a short password for the rehearsal and without special characters.
The result: the password for root is not accepted. under ssh.
I have also disabled password login and root with password under Administration/ssh.
The entered key is not used.
Under freeNAS in jail I did not have such problems. That is to say, I have been very busy with ssh.
yes I'am sure
1 Like
In case it wasn't obvious, my sharing of screenshots was a subtle hint to do the same. Too subtle, perhaps.
The old adage "a picture paints a thousand words" is a cliché for a reason: it's true.
If you can show us what you see, to support your explaining what you believe to be happening, that may help us to offer advice which may assist you in your endeavours.
Ultimately, something might be badly broken to the point where you might not be able to fix it with the GUI. There might not be an easy solution. If that's the case, @lleachii's earlier observation about having to reset to defaults should be borne in mind.
2 Likes
ummm...???
Let me provide a pic too:
You need to set this to use password and key.
1 Like
~]$ ssh root@192.168.0.1
root@192.168.0.1's password:
Permission denied, please try again.
root@192.168.0.1's password:
1 Like