Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've had OpenSSH server running on my debian server for a couple weeks and all of a sudden now when I go to login the next day it rejects my ssh key and I have to manually add a new one each time.

Not only that but I have the "tunneling with clear-text passwords" option enabled and the non-root (login with root is disabled) account for that is rejected too.

I'm at a loss why this is happening and I can't find any ssh options that would explain it.


I just changed debug level to DEBUG. But before that I'm seeing a lot of the following in auth.log

Feb  1 04:23:01 greenpages CRON[7213]: pam_unix(cron:session): session opened for user root by (uid=0)
Feb  1 04:23:01 greenpages CRON[7213]: pam_unix(cron:session): session closed for user root
Feb  1 04:36:26 greenpages sshd[7217]: reverse mapping checking getaddrinfo for [xx.xx.xx.xx] failed - POSSIBLE BREAK-IN ATTEMPT!
Feb  1 04:37:31 greenpages sshd[7223]: Did not receive identification string from xx.xx.xx.xx

My sshd_conf file settings are:

# Package generated configuration file
# See the sshd(8) manpage for details

# What ports, IPs and protocols we listen for
Port xxx
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_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 DEBUG

# 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 no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/

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

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

UsePAM no

ClientAliveInterval 60

AllowUsers myuser
share|improve this question
You can check the system/ssh logs: /var/log/syslog, /var/log/auth.log.. – Khaled Feb 1 '11 at 5:17
up vote 0 down vote accepted

My first guess is that this is something about ssh-agent on your client machine. The next time this happens, run ssh-add -l on your client and see if any keys are reported as loaded. If not, try

eval `ssh-agent`

to add them, then try ssh-ing into the server. If that works, you've found your problem. You can follow these instructions to automate ssh-agent on startup for debian.

Another thing to try is turning up the logging level when you ssh into the server, with

ssh -vvv

and look at the debug output to determine where it is failing. On the server, /var/log/auth.log or /var/log/messages may provide some clues, especially if you edit /etc/ssh/sshd_config on the server, change the debug level to DEBUG, and kill -HUP the server ssh process to force it to reload it's config. That will put lots more info in the server logs for you to look at. Remember to turn the logging level back down after you solve the problem.

share|improve this answer
I will check all that. But I think that doesn't explain why logging in without a key is rejected also. – EddyR Feb 1 '11 at 5:19
Well, hopefully increasing your logging level on both the client and server will give you some clues to why your logins are failing. – Phil Hollenback Feb 1 '11 at 5:40
Okay, so I understand now that if you have a key ssh will always check for it even if your trying to login with a password. The error returned on an attempted login is "permission denied (publickey)" and I know all the permissions are correct. hmmm... – EddyR Feb 1 '11 at 7:11
Well, I'm not sure exactly what's happened but everything has been running fine for the last few days. The only difference was I used the ssh-add command. – EddyR Feb 5 '11 at 8:42

I am going to guess that you may have an issue with either forward lookup or reverse lookup for whatever you are ssh'ing into or from. For both systems, make sure that you can do a forward/reverse lookup, and that you are not your names for both match.


dig sys_hostname.domain.dom result :

dig -x result : sys_hostname.domain.dom

share|improve this answer

Your Answer


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.