No longer able to log into ssh. Password right but "permission denied"

Baix · 07-06-2005, 03:06 PM

I've been using ssh for a while and its worked perfectly however now when I try to login...

Code:

login...andrew@tux ~ $ ssh localhost
Password: (mypassword)
Password: (mypassword)
Password: (mypassword)
Permission denied (publickey,keyboard-interactive).

However, when logging in as root it works perfectly. Unfortunatly I prefer to disable root logins. I can't think of anything that has changed that would have caused this problem. Thanks for any help!

Matir · 07-06-2005, 03:28 PM

Can you log in locally without a problem? Have you tried resetting the password as root? Can you post your sshd_config?

Baix · 07-06-2005, 03:35 PM

Locally, all the passwords are fine, logging in, su'ing etc.

Quote:

Have you tried resetting the password as root?

I've done everything from change passwords to delete and recreate users.

As for my sshd config:

Code:

#       $OpenBSD: sshd_config,v 1.69 2004/05/23 23:59:53 dtucker Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

#Port 22
Protocol 2
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768
# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys

# 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

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, PermitEmptyPasswords, and
# "PermitRootLogin without-password". If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no
UsePAM yes

#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yesI've done everything from change passwords to delete and recreate users.
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10

# no default banner path
#Banner /some/path

# override default of no subsystems
Subsystem       sftp    /usr/lib/misc/sftp-server

Baix · 07-06-2005, 03:36 PM

Here's the result of trying to log in with ssh -v:

Code:

ssh -v localhost
OpenSSH_3.9p1, OpenSSL 0.9.7e 25 Oct 2004
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/andrew/.ssh/identity type -1
debug1: identity file /home/andrew/.ssh/id_rsa type -1
debug1: identity file /home/andrew/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
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 'localhost' is known and matches the RSA host key.
debug1: Found key in /home/andrew/.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: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/andrew/.ssh/identity
debug1: Trying private key: /home/andrew/.ssh/id_rsa
debug1: Trying private key: /home/andrew/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
Password: 
debug1: Authentications that can continue: publickey,keyboard-interactive
Password: 
debug1: Authentications that can continue: publickey,keyboard-interactive
Password: 
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: No more authentication methods to try.
Permission denied (publickey,keyboard-interactive).

Matir · 07-06-2005, 03:38 PM

Hrrm, that looks just fine. Try looking in your logs. Usually a more verbose message gets logged.

Very often, the log will be /var/log/secure, /var/log/sshd, or similar.

Baix · 07-06-2005, 03:42 PM

there we no logs specific for ssh however it looks like it may have to have something to do with PAM. Also notice how it still lets root in (when "permitrootlogin=yes" of coarse).

Code:

less /var/log/messages | grep ssh:

Jul  6 14:56:26 tux sshd[19110]: Server listening on 0.0.0.0 port 22.
Jul  6 14:57:00 tux sshd[19136]: error: PAM: Authentication failure for andrew from tux.linuxbox.com
Jul  6 14:57:05 tux sshd[19136]: error: PAM: Authentication failure for andrew from tux.linuxbox.com
Jul  6 14:57:16 tux sshd[19136]: error: PAM: Authentication failure for andrew from tux.linuxbox.com
Jul  6 15:02:10 tux sshd[19274]: error: PAM: Authentication failure for andrew from tux.linuxbox.com
Jul  6 15:02:14 tux sshd[19274]: error: PAM: Authentication failure for andrew from tux.linuxbox.com
Jul  6 15:02:20 tux sshd[19274]: error: PAM: Authentication failure for andrew from tux.linuxbox.com
Jul  6 15:04:57 tux sshd[19335]: Accepted keyboard-interactive/pam for root from 127.0.0.1 port 56772 ssh2
Jul  6 15:04:57 tux sshd(pam_unix)[19341]: session opened for user root by root(uid=0)
Jul  6 15:13:08 tux sshd[19442]: error: PAM: Authentication failure for andrew from tux.linuxbox.com
Jul  6 15:14:12 tux sshd(pam_unix)[19501]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=tux.linuxbox.com  user=brian
Jul  6 15:14:14 tux sshd[19496]: error: PAM: Authentication failure for brian from tux.linuxbox.com
Jul  6 15:14:21 tux sshd[19496]: error: PAM: Authentication failure for brian from tux.linuxbox.com
Jul  6 15:14:22 tux sshd(pam_unix)[19503]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=tux.linuxbox.com  user=brian
Jul  6 15:14:24 tux sshd[19496]: error: PAM: Authentication failure for brian from tux.linuxbox.com
Jul  6 15:16:05 tux sshd[19521]: error: PAM: Authentication failure for andrew from tux.linuxbox.com
Jul  6 15:17:09 tux sshd[19528]: error: PAM: Authentication failure for andrew from tux.linuxbox.com
Jul  6 15:17:13 tux sshd[19528]: error: PAM: Authentication failure for andrew from tux.linuxbox.com
Jul  6 15:17:18 tux sshd[19528]: error: PAM: Authentication failure for andrew from tux.linuxbox.com
Jul  6 15:35:57 tux sshd[19785]: error: PAM: Authentication failure for andrew from tux.linuxbox.com
Jul  6 15:36:01 tux sshd[19785]: error: PAM: Authentication failure for andrew from tux.linuxbox.com
Jul  6 15:36:05 tux sshd[19785]: error: PAM: Authentication failure for andrew from tux.linuxbox.com

Matir · 07-06-2005, 04:19 PM

I guess it's time to turn to your attention to /etc/pam.d/sshd. What does that file contain?

Baix · 07-06-2005, 04:23 PM

Thanks for your help so far Matir

/etc/pam.d/sshd

Code:

#%PAM-1.0

auth       required     pam_stack.so service=system-auth
auth       required     pam_shells.so
auth       required     pam_nologin.so
account    required     pam_stack.so service=system-auth
password   required     pam_stack.so service=system-auth
session    required     pam_stack.so service=system-auth

Matir · 07-06-2005, 04:33 PM

Quite perplexing. Your pam.d/sshd is identical to mine (Gentoo defaults for the 2005.0 profile). I don't suppose the file /etc/nologin exists?

Also, try to grep pam in /var/log/messages. Perhaps it's giving a more verbose message through pam. Interestingly enough, pam_stack should handle local logins and ssh logins the same, so only pam_shell and pam_nologin should matter.

Baix · 07-06-2005, 04:40 PM

Thank you soo much. For some odd reason a /etc/nologin had been created with a line about "system is going down for a shutdown, blah blah" message. I deleted it and now all looks fine so far.
Once again, thanks!

Matir · 07-06-2005, 04:43 PM

LOL, glad it's working. Might want to keep an eye out for that popping up again. I can't imagine what would cause it.

emallove · 11-21-2008, 01:44 PM

I had the same problem. I was unable to SSH to host-xyz, while other folks in my same unix group were able to. I was seeing this in /var/log/messages:

sshd[4191]: error: PAM: Authentication failure for emallove ...

The problem was that somehow an account for "emallove" had been created on the local system which was apparently overriding our shared LDAP passwd file. After deleting the "emallove" line from /etc/passwd I can now SSH to host-xyz.