sshd Authentication Issues

skarphace · 2009-01-07 23:24:48

First time setting up an Arch for use as a server. This machine is to be headless, so before I can even continue, I need sshd setup. Followed the wiki and tried IRC, to no avail. There's no GUI so none of this is cut and pasted so if you see something missing, let me know.

sshd_config

ListenAddress 0.0.0.0
Protocol 2
UsePAM Yes
PermitRootLogin yes(just for testing)
ChallengeResponseAuthentication no

auth.log

Failed password for <user> from <host> port <portnum> ssh2

errors.log

sshd[pid]: error: PAM: Authentication falure for <user> from <host>

hosts.allow

sshd: ALL

hosts.deny

ALL: ALL: DENY

sshd is accepting connections but for some reason auth fails. And yes, both users on this machine(mike and root) can authenticate on the local console.

mike@skinner ~ $ ssh 10.0.0.20
mike@10.0.0.20's password: 
Permission denied, please try again.

mike@skinner ~ $ ssh root@10.0.0.20
root@10.0.0.20's password: 
Permission denied, please try again.

Any information or even guesses would be appreciated.

Mektub · 2009-01-07 23:54:31

skarphace,

how about ~/.ssh/ssh_known_hosts ?

There is also a /etc/ssh/ssh_known_hosts that I never used.

From the /etc/ssh/sshd_config file:

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

Mektub

fukawi2 · 2009-01-08 01:14:52

Try stopping sshd on your server, then running this on your server when you attempt to connect and see if it gives you anything useful:

/usr/sbin/sshd -d

You have to run it using the full path or it will complain.

It will run a single instance of the ssh server in the foreground with debug output. (ie, it won't fork)

Pudge · 2009-01-08 01:41:32

Try this guide and see if you can get it going.

Pudge

skarphace · 2009-01-08 16:04:27

Mektub wrote:

how about ~/.ssh/ssh_known_hosts ?

Yes, there's an entry for this machine on my workstation.

fukawi2 wrote:

/usr/sbin/sshd -d

Yes, I have done this before, and have just again. There is nothing interesting, everything looks like it was just a bad typed password. 'password authentication failed for mike'.

skarphace · 2009-01-12 15:55:22

Pudge wrote:

Try this guide and see if you can get it going.

This guide had nothing unusual but it did point out an error in my hosts.allow file. Fixing that still had no affect. Log entries still the same and same problem.

polarbear · 2009-01-12 16:09:20

Have you meddled with /etc/pam.d/* ?

skarphace · 2009-01-12 17:26:47

polarbear wrote:

Have you meddled with /etc/pam.d/* ?

I remember looking around those files when the problem presented itself but I'm 90% sure I changed nothing. Any specific file I should check?

.:B:. · 2009-01-12 17:29:40

Did you turn on the verbose option (-v) while SSH'ing into the server? That might tell you some more...

skarphace · 2009-01-12 18:45:45

B wrote:

Did you turn on the verbose option (-v) while SSH'ing into the server? That might tell you some more...

Yes, I did. However, all it has is password auth failed for user, nothing appears unusual.

.:B:. · 2009-01-12 19:09:22

Could you post the output nonetheless? You might be overlooking something . Better safe than sorry, I'd say.

skarphace · 2009-01-12 19:18:51

B wrote:

Could you post the output nonetheless? You might be overlooking something . Better safe than sorry, I'd say.

Sure 'nuff.

mike@skinner ~ $ ssh -v 10.0.0.20
OpenSSH_4.7p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 10.0.0.20 [10.0.0.20] port 22.
debug1: Connection established.
debug1: identity file /home/mike/.ssh/identity type -1
debug1: identity file /home/mike/.ssh/id_rsa type 1
debug1: identity file /home/mike/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.0
debug1: match: OpenSSH_5.0 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '10.0.0.20' is known and matches the RSA host key.
debug1: Found key in /home/mike/.ssh/known_hosts:73
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/mike/.ssh/identity
debug1: Offering public key: /home/mike/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: /home/mike/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
mike@10.0.0.20's password: 
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
mike@10.0.0.20's password: 
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
mike@10.0.0.20's password: 
debug1: Authentications that can continue: publickey,password
debug1: No more authentication methods to try.
Permission denied (publickey,password).

.:B:. · 2009-01-12 19:40:49

mike@10.0.0.20's password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
mike@10.0.0.20's password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
mike@10.0.0.20's password:
debug1: Authentications that can continue: publickey,password
debug1: No more authentication methods to try.
Permission denied (publickey,password).

I've had that too.

Edit: sorry, i saw you are using SSH keys. Try increasing the MaxAuthTries value in /etc/ssh/sshd_config to see if that helps any.

brisbin33 · 2009-01-12 19:50:01

FWIW here's my working sshd_config. i had some trial/error time getting it up and going.

i use public/private RSA keys, and i highly recommend doing the same.

Protocol 2

LoginGraceTime 120
PermitRootLogin no
StrictModes yes
MaxAuthTries 3

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      /path/to/authorized_keys
RhostsRSAAuthentication no
HostbasedAuthentication no
IgnoreUserKnownHosts yes
IgnoreRhosts yes
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes

also (as i made this mistake) since sshd is started as a daemon (i believe as root) make sure you're editing /etc/ssh/sshd_config and not ~/.ssh/sshd_config

.:B:. · 2009-01-12 19:54:00

sshd_config in your ~ will provide additional configurability but I don't think it allows to override (ie loosen) the central settings. I do think it allows for more strict settings though.

fukawi2 · 2009-01-12 21:43:07

skarphace wrote:

fukawi2 wrote:
/usr/sbin/sshd -d
Yes, I have done this before, and have just again. There is nothing interesting, everything looks like it was just a bad typed password. 'password authentication failed for mike'.

This is an interesting one... Try increasing the debug level by using -dd or -ddd and see if the higher level of output gives anything that the standard debug doesn't...?

KimTjik · 2009-01-12 22:42:49

Maybe a stupid question, but you did export the public key to the working station you're trying to connect from?

Next I wonder whether you actually have the line "AuthorizedKeysFile /path/to/authorized_keys" without a "#" before it to disable it, or you're just not showing what path you in reality have?

I would still recommend that you add a user without administration privileges first. Create a set of key in that users .ssh directory. For this you don't need to set any path because its the default location SSH will check. I think this is an easier way to set up things, because in the end you should enable root login anyway, so why play around with different sets of keys?

skarphace · 2009-01-12 23:18:25

B wrote:

Edit: sorry, i saw you are using SSH keys. Try increasing the MaxAuthTries value in /etc/ssh/sshd_config to see if that helps any.

I am not using publickeys with this machine(yet). My client does try and use them but the server is not aware so it should fall back to password auth(which is what debug output says it does). Before I even bother with publickeys, I would really like password auth to work.

fukawi2 wrote:

This is an interesting one... Try increasing the debug level by using -dd or -ddd and see if the higher level of output gives anything that the standard debug doesn't...?

Nothing terribly exciting but here's the jist(summary) of it:

Failed none for mike on <IP> Port <port> ssh2
Failed publickey for mike on <IP> Port <port> ssh2
Failed publickey for mike on <IP> Port <port> ssh2
Failed password for mike on <IP> Port <port> ssh2

The debug output seems normal to me.

KimTjik wrote:

Maybe a stupid question, but you did export the public key to the working station you're trying to connect from?

Not using pubkeys yet.

KimTjik wrote:

I would still recommend that you add a user without administration privileges first. Create a set of key in that users .ssh directory. For this you don't need to set any path because its the default location SSH will check. I think this is an easier way to set up things, because in the end you should enable root login anyway, so why play around with different sets of keys?

Of course, I just allowed root for testing during this problem.

EDIT: Also, setting MaxAuthTries to 3 kills it. So I bumped that back up. Also, just upgraded openssh and behavior is the same. The only difference is that sshd drops on disconnect when run manually. Or I just noticed it now and it did that before.

Last edited by skarphace (2009-01-12 23:37:56)

.:B:. · 2009-01-13 00:22:12

You should raise the number. As you say yourself your client tries to feed them to the server, the server keeps track of the failures, and throws you out . You should try to increase them, not decrease . By default they're at 6 I think.

skarphace · 2009-01-13 15:18:48

B wrote:

You should raise the number. As you say yourself your client tries to feed them to the server, the server keeps track of the failures, and throws you out . You should try to increase them, not decrease . By default they're at 6 I think.

Indeed. I have raised it to 9 but this is not the problem.

Arch Linux

#1 2009-01-07 23:24:48

sshd Authentication Issues

#2 2009-01-07 23:54:31

Re: sshd Authentication Issues

#3 2009-01-08 01:14:52

Re: sshd Authentication Issues

#4 2009-01-08 01:41:32

Re: sshd Authentication Issues

#5 2009-01-08 16:04:27

Re: sshd Authentication Issues

#6 2009-01-12 15:55:22

Re: sshd Authentication Issues

#7 2009-01-12 16:09:20

Re: sshd Authentication Issues

#8 2009-01-12 17:26:47

Re: sshd Authentication Issues

#9 2009-01-12 17:29:40

Re: sshd Authentication Issues

#10 2009-01-12 18:45:45

Re: sshd Authentication Issues

#11 2009-01-12 19:09:22

Re: sshd Authentication Issues

#12 2009-01-12 19:18:51

Re: sshd Authentication Issues

#13 2009-01-12 19:40:49

Re: sshd Authentication Issues

#14 2009-01-12 19:50:01

Re: sshd Authentication Issues

#15 2009-01-12 19:54:00

Re: sshd Authentication Issues

#16 2009-01-12 21:43:07

Re: sshd Authentication Issues

#17 2009-01-12 22:42:49

Re: sshd Authentication Issues

#18 2009-01-12 23:18:25

Re: sshd Authentication Issues

#19 2009-01-13 00:22:12

Re: sshd Authentication Issues

#20 2009-01-13 15:18:48

Re: sshd Authentication Issues

Board footer