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 am trying to do ssh hardening on my server but looks like it just blocks everyone. I checked auth.log on target server and it just says: "Connection closed by x.x.x.x [preauth]" Let me paste the sshd_config here:

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

# What ports, IPs and protocols we listen for
Port 1000
# 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
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 no    

# 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/    

# 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
AllowUsers <myusername>

I have matched my public key with the authorized_keys file under the username's home directory on the target server. What can be wrong here?

I am trying to do ssh like this:

ssh -p 1000 username@serverhostname

And in my local it keeps saying:

Ubuntu 12.04.2 LTS
Permission denied (publickey).
share|improve this question
For all these questions, my main technique is to run a non-forking, logging copy of the server temporarily on a second port (opening the firewall as needed) with /sbin/sshd -d -f /path/to/conffile -p 1001, then connect with a client pointing to port 1001. The information given to the client about auth failures is deliberately sketchy, but the server will tell you much more (what file did it look at? why did it not like it? etc.). – MadHatter Dec 4 '13 at 9:26
I figured out the issue. Issue was that the file('.ssh/authorized_keys') was created by root user and when <username> was trying to do the ssh then there was a permission problem for that directory /home/username/.ssh/authorized_keys I found the issue after i set the Log level as DEBUG instead of INFO which gave the detailed information about the permission. Solved the issue now. Thanks thought for the response – Keshav Agrawal Dec 5 '13 at 13:48
Glad you've solved it! Yes, DEBUG logging level is the same sort of information you get on STDOUT when you run the daemon with -d, so you took another path to the same source of useful information. You may want to write up your answer and accept it, to prevent this question from sitting around indefinitely; alternatively, delete this question. – MadHatter Dec 5 '13 at 14:34
up vote 3 down vote accepted

I have solved the issue and figured out that the directory(.ssh) and the file(authorized_keys) for that particular user was created by root and so when local was trying to login with there was a permission issue for the file /home/username/.ssh/authorized_keys

How did I figure it out?

INFO log level was not helping so I tried putting DEBUG mode in sshd_config and put a tailf on /var/log/auth.log on remote server and then tried to login with:

ssh -p <port number> username@serverhost

and saw on auth.log that there was a permission error on authorized_keys file. I changed the permission of that file chown'ed' that directory and then did the login and all was working!

Thanks all!

share|improve this answer
SSH is very pernickety about ownership of the .ssh directory (with good reason). You should mark this as the accepted answer. – ldrumm Dec 6 '13 at 6:25
Yes Idrumm, it is. I will mark this after 3 hours(SO rule :)) – Keshav Agrawal Dec 6 '13 at 6:31

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.