Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm trying to login to my ssh server using a username and password, but I get this error after entering the correct password:

Permission denied, please try again.

I can login using a pubkey on another machine, though, but I have NOT disabled regular password authentication. The only thing I disabled was root logins.

Here's my sshd_config file:

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

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

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts

RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication yes

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

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60 
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# 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 and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes 
IgnoreUserKnownHosts no
PasswordAuthentication yes

I've added the last 2 lines in a latest attempt at getting it to work. (I have them on my other vps, and they work there)

Here's the listing of the ~/.ssh/ directory of my user:

ls -la /home/skerit/.ssh
total 16
drwx------ 2 skerit skerit 4096 2011-06-25 15:11 .
drwxr-xr-x 4 skerit skerit 4096 2011-07-07 21:05 ..
-rw-r--r-- 1 skerit skerit 1882 2011-06-25 15:15 authorized_keys
-rw-r--r-- 1 skerit skerit 884 2011-06-23 22:59 known_hosts 

This is the output of /usr/sbin/sshd -d:

debug1: userauth-request for user skerit service ssh-connection method none
debug1: attempt 0 failures 0
debug1: PAM: initializing for "skerit"
debug1: PAM: setting PAM_RHOST to "82.197.70.70"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user skerit service ssh-connection method publickey
debug1: attempt 1 failures 0
debug1: test whether pkalg/pkblob are acceptable
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: temporarily_use_uid: 1000/1000 (e=0/0)
debug1: trying public key file /home/skerit/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 1000/1000 (e=0/0)
debug1: trying public key file /home/skerit/.ssh/authorized_keys2
debug1: Could not open authorized keys '/home/skerit/.ssh/authorized_keys2': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for skerit from 82.197.70.70 port 57154 ssh2
debug1: userauth-request for user skerit service ssh-connection method password
debug1: attempt 2 failures 1
debug1: PAM: password authentication failed for skerit: Authentication failure
Failed password for skerit from 82.197.70.70 port 57154 ssh2 

I then tried to login to the ssh server FROM the ssh server (locally) using THE SAME username and password, and it worked. This was in the auth.log file:

Jul 8 12:21:50 vpsnl1 sshd[27298]: debug1: could not open key file '/etc/ssh/ssh_host_ecdsa_key': No such file or directory
Jul 8 12:21:50 vpsnl1 sshd[27298]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Jul 8 12:22:16 vpsnl1 sshd[27298]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=82.197.70.70 user=
skerit
Jul 8 12:23:50 vpsnl1 sshd[27439]: Server listening on 0.0.0.0 port 22.
Jul 8 12:23:50 vpsnl1 sshd[27439]: Server listening on :: port 22.
Jul 8 12:24:07 vpsnl1 sshd[27458]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Jul 8 12:24:14 vpsnl1 sshd[27458]: Accepted password for skerit from 127.0.0.1 port 57667 ssh2
Jul 8 12:24:14 vpsnl1 sshd[27458]: pam_unix(sshd:session): session opened for user skerit by (uid=0)
Jul 8 12:24:25 vpsnl1 sshd[27471]: Received disconnect from 127.0.0.1: 11: disconnected by user
Jul 8 12:24:25 vpsnl1 sshd[27458]: pam_unix(sshd:session): session closed for user skerit 
share|improve this question
    
Could you add your ssh-config? –  Bart De Vos Jul 8 '11 at 9:42
    
Alright, config file added! –  skerit Jul 8 '11 at 9:46
    
How about permisions on .ssh? Could you post ls -la ~/.ssh on the server? –  mkudlacek Jul 8 '11 at 9:56
    
Ok, I've added the listing of the files of the user I'm trying to login as. –  skerit Jul 8 '11 at 9:58
1  
Authorized_keys shouldn't be world-readable I think, but it doesn't explain why you can't login with password. Can you do su skerit in your account? –  mkudlacek Jul 8 '11 at 10:08

1 Answer 1

up vote 4 down vote accepted

Are you certain that the user account you're attempting to access is correctly configured? If you log in as root on the system, can you su to the user account?

# su - username

What do you see in your logs after a failed connection attempt? On many systems, sshd will log to something /var/log/secure or /var/log/auth.log. Also, I note that you have PasswordAuthentication enabled but ChallengeResponseAuthentication disabled. Do you see the same behavior if you enable ChallengeResponseAuthentication?

Here are some general diagnostic steps to use when you have ssh problems:

  • Enable verbose diagnostics in ssh:

    ssh -v host.example.com
    

    This will cause the client to output a variety of diagnostic messages as it negotiates the connection. This will often provide a clue to the problem.

  • Run the server in debug mode.

    On your server, stop sshd, then run it from the command line like this:

    /usr/sbin/sshd -d
    

    This will produce verbose debug logging on stderr that will very often contain useful information.

If neither of these helps you figure out what's going on, would you add the output to your question?

share|improve this answer
    
Ok, I've added the output. Basically: when I tro a remote login it says the password isn't good, when I try a local login it says the password is ok and lets me in. –  skerit Jul 8 '11 at 10:26
1  
It WAS the password. I changed the password through a web console (some java application) and even though the entered password was IDENTICAL to what I typed in my putty console, somehow the ascii values must have differed. I changed it to something simpler, logged in the correct way through putty, and changed it back again. Now it works. –  skerit Jul 8 '11 at 11:13
    
@skerit - probably had a character encoding issue, then - maybe UTF8 vs ASCII? –  warren Jul 8 '11 at 12:15
    
Glad to hear things are working! –  larsks Jul 8 '11 at 12:56

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.