Unable to login via ssh

Post Reply
whiznat
Posts: 6
Joined: Fri Oct 14, 2011 2:13 am

Unable to login via ssh

Post by whiznat » Fri Oct 14, 2011 2:37 am

Did an apt-get update, then apt-get install dropbear, seemed to install properly, but cannot login.
I created an unprivileged account on the Iomega and couldn't login to that either.
After 3 tries it tells me

Permission denied (publickey,password).

Is there some configuration setting I need to set?

robertirons
Posts: 3
Joined: Fri Sep 23, 2011 9:46 pm

Re: Unable to login via ssh

Post by robertirons » Thu Oct 20, 2011 10:44 pm

Hi,
I am having the same problem, I assumed the passwords would be the same as for telnet access, but its not working! Any ideas?

whiznat
Posts: 6
Joined: Fri Oct 14, 2011 2:13 am

Re: Unable to login via ssh

Post by whiznat » Fri Oct 21, 2011 2:20 am

Here is a full log of the transaction. Anyone see anything that looks like a problem?

whiznat@Whiznat ~ > ssh -vvv nascentral@192.168.1.221
OpenSSH_5.9p1, OpenSSL 0.9.8r 8 Feb 2011
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.221 [192.168.1.221] port 22.
debug1: Connection established.
debug1: identity file /home/whiznat/.ssh/id_rsa type -1
debug1: identity file /home/whiznat/.ssh/id_rsa-cert type -1
debug1: identity file /home/whiznat/.ssh/id_dsa type -1
debug1: identity file /home/whiznat/.ssh/id_dsa-cert type -1
debug1: identity file /home/whiznat/.ssh/id_ecdsa type -1
debug1: identity file /home/whiznat/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version dropbear_0.51
debug1: no match: dropbear_0.51
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "192.168.1.221" from file "/home/whiznat/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/whiznat/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,aes256-cbc,twofish256-cbc,twofish-cbc,twofish128-cbc,blowfish-cbc
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,aes256-cbc,twofish256-cbc,twofish-cbc,twofish128-cbc,blowfish-cbc
debug2: kex_parse_kexinit: hmac-sha1-96,hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: hmac-sha1-96,hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: zlib,none
debug2: kex_parse_kexinit: zlib,none
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug2: dh_gen_key: priv key bits set: 132/256
debug2: bits set: 475/1024
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: RSA 37:03:60:f7:22:4f:91:64:6e:5c:b2:d6:63:7d:13:87
debug3: load_hostkeys: loading entries for host "192.168.1.221" from file "/home/whiznat/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/whiznat/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys
debug1: Host '192.168.1.221' is known and matches the RSA host key.
debug1: Found key in /home/whiznat/.ssh/known_hosts:2
debug2: bits set: 492/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/whiznat/.ssh/id_rsa (0x0)
debug2: key: /home/whiznat/.ssh/id_dsa (0x0)
debug2: key: /home/whiznat/.ssh/id_ecdsa (0x0)
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/whiznat/.ssh/id_rsa
debug3: no such identity: /home/whiznat/.ssh/id_rsa
debug1: Trying private key: /home/whiznat/.ssh/id_dsa
debug3: no such identity: /home/whiznat/.ssh/id_dsa
debug1: Trying private key: /home/whiznat/.ssh/id_ecdsa
debug3: no such identity: /home/whiznat/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
nascentral@192.168.1.221's password:
debug3: packet_send2: adding 48 (len 65 padlen 15 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
nascentral@192.168.1.221's password:
debug3: packet_send2: adding 48 (len 65 padlen 15 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
nascentral@192.168.1.221's password:
debug3: packet_send2: adding 48 (len 65 padlen 15 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,password).

Thanks.

Mijzelf
Posts: 6226
Joined: Mon Jun 16, 2008 10:45 am

Re: Unable to login via ssh

Post by Mijzelf » Fri Oct 21, 2011 5:58 pm

The log looks normal to me.

Can you still logon via telnet using the same name/password? Maybe you can get information from the serverside. Have a look at /var/log/daemon.log. If it doesn't contain anything interesting, kill dropbear, and start it over with -EF, to keep it on foreground, and log to stderr. (And use the other flags which are used normally by /etc/init.d/dropbear.

whiznat
Posts: 6
Joined: Fri Oct 14, 2011 2:13 am

Re: Unable to login via ssh

Post by whiznat » Sat Oct 22, 2011 3:45 am

Well now we're getting somewhere. dropbear is running but generates this error message on start:

root@Iomega NAS:/etc/init.d# /usr/sbin/dropbear -EF -d /etc/dropbear/dropbear_dss_host_key -r /etc/dropbear/dropbear_rsa_host_key -p 22 -W 65536
[10180] Oct 21 23:35:55 Failed listening on '22': Error listening: Address family not supported by protocol
[10180] Oct 21 23:35:55 premature exit: No listening ports available.

Please tell me how to convince Debian that's it's ok to listen for ssh connections on port 22.

I would also like to point out that editing the port forwarding rules in my router will allow connections from outside my LAN. That is definitely NOT what I want. The problem is that the NAS won't allow dropbear to listen on port 22. Thanks.

UPDATE: netstat -ap yields this line:

tcp 0 0 *:ssh *:* LISTEN 1404/dropbear

and netstat -nap yields

tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1404/dropbear

which indicates that dropbear is listening on port 22, but clearly something is wrong.

Mijzelf
Posts: 6226
Joined: Mon Jun 16, 2008 10:45 am

Re: Unable to login via ssh

Post by Mijzelf » Sat Oct 22, 2011 8:31 am

Did you check if dropbear was gone *before* you started it manually? If it was, than the listening dropbear is the one you started. Are you running standard firmware? If you upgraded the kernel, the error could be from binding to ipv6. I don't know if dropbear supports that.

Anyway, when dropbear stays on foreground, it's still running. So try to login, and see what happens.

whiznat
Posts: 6
Joined: Fri Oct 14, 2011 2:13 am

Re: Unable to login via ssh

Post by whiznat » Sat Oct 22, 2011 5:51 pm

Well I'm sure I ran /etc/init.d/dropbear stop before I executed that command, but I tried again.

nascentral@Iomega NAS:~$ ps -e | grep drop
1404 ? 00:00:00 dropbear
nascentral@Iomega NAS:~$ su
Password:
root@Iomega NAS:/home/nascentral# /etc/init.d/dropbear stop
Stopping Dropbear SSH server: dropbear.
root@Iomega NAS:/home/nascentral# netstat -nap | grep drop

No results; dropbear is not running. But here is where it gets interesting. I restarted dropbear and this time I got no errors. Then I tried to login via ssh from another window, and look what happens.

root@Iomega NAS:/home/nascentral# /usr/sbin/dropbear -EF -d /etc/dropbear/dropbear_dss_host_key -r /etc/dropbear/dropbear_rsa_host_key -p 22 -W 65536
[23625] Oct 22 13:26:56 Running in background
root@Iomega NAS:/home/nascentral# [23710] Oct 22 13:27:40 Child connection from 192.168.1.115:49321
[23710] Oct 22 13:27:59 user 'nascentral' has blank password, rejected
[23710] Oct 22 13:28:19 user 'nascentral' has blank password, rejected
[23710] Oct 22 13:28:22 user 'nascentral' has blank password, rejected
[23710] Oct 22 13:28:22 exit before auth (user 'nascentral', 3 fails): Exited normally

I am *certain* that I am typing in the password, but for some reason dropbear is convinced it's blank. I'm not sure if this means the password in /etc/passwd is blank (it's not) or if it means that dropbear thinks my terminal is sending a blank password.

I do remember that on one of the posts or guides here on this site I was told to muck about with the /etc/gshadow file. Perhaps I messed something up?

Here are a few snippets from /etc/shadow:

root::14517:0:99999:7:::
nascentral::14517:0:99999:7:::
noob:!:15094:0:99999:7::: <- unprivileged account I made

and a few snippets from /etc/gshadow:

root:*::
nascentral:!::
noob:!::

and a few snippets from /etc/passwd: (hashes replaced with asterisks; there are real hashes there)

root:****/:0:0:root:/root:/bin/bash
nascentral:*****/:1000:1000:root:/home/nascentral:/bin/bash
noob:****/:1001:1001::/home/noob:/bin/sh

Mijzelf
Posts: 6226
Joined: Mon Jun 16, 2008 10:45 am

Re: Unable to login via ssh

Post by Mijzelf » Sun Oct 23, 2011 12:51 pm

whiznat wrote:I'm not sure if this means the password in /etc/passwd is blank (it's not) or if it means that dropbear thinks my terminal is sending a blank password.
It means the password on serverside is blank. That is not necessarily in /etc/password. On most Linux (and other Unix variant) systems the password is not in /etc/passwd, but in /etc/shadow. In /etc/passwd then a 'x' is posed.
The reason is that /etc/passwd needs to be world readable (for instance to be able to read the owner of a file). In earlier times world readability in combination with a password hash was considered to be safe enough. Later the actual password hash was moved to a more restricted file (only root can read/write it) /etc/shadow.

Anyway, I suppose you have to supply a password when logging in as nascentral via telnet, so it's definitely not empty. I'm not sure if gshadow has anything to do with it. You're trying to login as user, not as group, so logically /etc/group and /etc/gshadow are not even read. But it could be a subtlety in the authentication api. I see one striking difference between your group/gshadow and mine, I don't have a 'nascentral' group.

Are the owner and access flags as they should be?

Code: Select all

Mijzelf@Iomega-09681e:/etc$ ls -l passwd shadow group gshadow
-rw-r--r-- 1 root root  624 Mar 27  2011 group
-rw------- 1 root root  518 Mar 27  2011 gshadow
-rw-r--r-- 1 root root 1506 Mar 27  2011 passwd
-rw------- 1 root root 1046 Mar 27  2011 shadow
Did you ever change the nascentral password on the box, using 'passwd'. That might help.

whiznat
Posts: 6
Joined: Fri Oct 14, 2011 2:13 am

Re: Unable to login via ssh

Post by whiznat » Mon Oct 31, 2011 11:53 pm

I am logging in with telnet, and it is requesting a password, which works.

My permissions on group and gshadow were 644 but changed them to be 600 to match yours, no joy.

Changed nascentral's password using passwd, again, no joy. I had to be root to run passwd; is that normal? Most systems let any user change their own password using passwd, but I couldn't even run it as an unprivileged user.

What group is your nascentral in?

Mijzelf
Posts: 6226
Joined: Mon Jun 16, 2008 10:45 am

Re: Unable to login via ssh

Post by Mijzelf » Tue Nov 01, 2011 6:22 pm

whiznat wrote:My permissions on group and gshadow were 644 but changed them to be 600 to match yours, no joy.
group and password should be 644, and shadow and gshadow 600.
whiznat wrote:What group is your nascentral in?
A nameless group '1000'.
whiznat wrote:I had to be root to run passwd; is that normal?
No. I suppose the suid bit isn't set?

Code: Select all

-rwsr-xr-x 1 root root 29820 Dec  6  2009 /usr/bin/passwd
BTW, don't expect my system to be virginal. If your want to see the original permissions on whatever, you'd better look in sda1-2064.tgz

Post Reply