Issue with SSH [SOLVED]

[darinschmidt]

Im trying to use FreeNAS to ssh to my ddwrt router. Everything seems to go well till the end where i always get permission denied. I have also posted this on DDWRT because i think its something with the router and not freenas but wanted to check.

This is what i get when i try to log into the router from FreeNAS.

With DDWRT you can choose to enable or disable password authentication. The user on the router is the same as the user on FreeNAS. A friend of mine mentioned checkign the netmask on both system, i'll do that when i get home after work today.

OpenSSH_5.4p1_hpn13v11 FreeBSD-20100308, OpenSSL 0.9.8q 2 Dec 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 192.168.2.1 [192.168.2.1] port 22.
debug1: Connection established.
debug1: identity file /mnt/Mass/Home/darin/.ssh/id_rsa type 1
debug1: identity file /mnt/Mass/Home/darin/.ssh/id_rsa-cert type -1
debug1: identity file /mnt/Mass/Home/darin/.ssh/id_dsa type 2
debug1: identity file /mnt/Mass/Home/darin/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version dropbear_2012.55
debug1: no match: dropbear_2012.55
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.4p1_hpn13v11 FreeBSD-20100308
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host '192.168.2.1' is known and matches the RSA host key.
debug1: Found key in /mnt/Mass/Home/darin/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
DD-WRT v24-sp2 std (c) 2012 NewMedia-NET GmbH
Release: 12/31/12 (SVN revision: 20453)
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /mnt/Mass/Home/darin/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Offering public key: /mnt/Mass/Home/darin/.ssh/id_dsa
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).


If i enable password authentication, i always get permission denied also and it doesnt accept the password i entered.

 

[fracai]

Have you added your public key to the authorized_hosts on your router? There should be a field for this in the router's web GUI. As for the password, try changing the password on the router and logging in with that. Note that you can probably set a password for SSH access that is different than for the web GUI.

 

[darinschmidt]

Yeah on the gui there is a key entry and i put the key in there from id_rsa.pub on the server. I did try resetting the pass on the router and had no luck with that. I also tried looking for another password field for ssh in the gui and wasnt successfull in finding anything. But DDWRT's wiki for ssh doesnt mention anything about that either. All they say in the wiki is to generate your key, enable sshd on the router, copy the pub key to the field in ddwrt save and apply settings. The one thing i wonder about as it says above: Offering public key: /mnt/Mass/Home/darin/.ssh/id_rsa but isnt this the private key? the public key has a .pub at the end right?

Am i right in assuming that its a permission/authentication issue? Not a protocol or anything considering the following?
debug1: Remote protocol version 2.0, remote software version dropbear_2012.55
debug1: no match: dropbear_2012.55
debug1: Enabling compatibility mode for protocol 2.0

edit:
The one thing i noticed from the ddwrt wiki states that the rsa key should have the followign format ssh-rsa code ssh-rsa comment.
The one i generated doesnt have the second ssh-rsa, just ssh-rsa code comment

 

[fracai]

It says "Offering public key /path/to/private_key", but I assume that that's just an identifier. I see the same output when I connect over SSH.

The errors that you're listing seem to indicate that the key isn't being accepted. Did you save your changes after pasting in the public key on the router? It'd be interesting to see the output when you connect with a password.

Oh, what user are you trying to connect as? You probably need to connect as root, so: 'ssh root@router' or 'ssh -l root router'. If you just try to ssh over without specifying a user, it'll try to login as the user that you're logged in as on the client (in this case, your FreeNAS box, which appears to be 'darin').

 

[darinschmidt]

Yeah i saved and applied settings everytime i changed settings. The user i have for my router is darin and the user im logged into on the server is darin. I thought that when i first logged into the router (when it asked to change admin password and such) that was the "root" user? So im assuming my username darin is root. I have tried logging in with a password and i forget what exactly it says but its the same output above except it doesnt accept the pass i'm typing in. I'll try root@ip when i get home.

Because of this debug line Host '192.168.2.1' is known and matches the RSA host key i thought that it was accepting the key but latter on seems like its having issues so im not 100% sure if it is or not.

Thanks for your help.

 

[fracai]

Yeah, I'm pretty sure that the GUI login is not the same as shell login. In other words, you changed the login credentials for the web GUI, but that only updates the root password for the shell login.

I'm betting that root@ip will work.

ALso, the known host stuff just means that the machine that you're connecting to has provided a key that matches one that you've connected to before. It's about identifying the remote machine, not the user key that is trying to authenticate. This information is stored on the client in the "~/.ssh/known_hosts" file. The purpose being that if you try to connect to a remote machine and someone intercepts the connection, they won't be able to provide the correct key and you'll abort the connection before providing a password. In reality, it means that the sysadmin of your university updated the keys and didn't send out an alert so you just ignore the warning and tell ssh to update your known_hosts file. For a router, you probably won't have to worry about it until you replace the router or reinstall your firmware.

 

[darinschmidt]

ok, that makes sense, thanks a ton. i'll give it a shot tonight when i get home and post an update.

 

[darinschmidt]

ok well that did the trick, using root. thanks!