Take the 2-minute tour ×

I have set up a home network behind a router a while ago and use openssh to access the network consisting of my laptop, wife's netbook and my desktop all running l/x/ubuntu 12.04. This worked perfectly for some time.

I am now only able to access from and to the netbook and the other 2, but no access between the laptop and desktop. I have never used the id_* route so have no id_* files in the ~/.ssh directories.

I have tried various strategies advised on forums such as this one eg. deleting the known_hosts and changing the configuration files such as the PasswordAuthentication to no, yes and commented out. None of which works.

The only thing I can think of is that my recent tinkering with setting up a vpn network between the laptop and desktop may have changed something to disrupt the working of ssh between these 2 machines. btw I have not managed to get the vpn to work yet (see previous post on this forum).

The /etc/ssh/sshd_config file on my desktop is:

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

# What ports, IPs and protocols we listen for
Port 22
#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 yes
StrictModes yes

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

IgnoreRhosts yes
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
#IgnoreUserKnownHosts yes

PermitEmptyPasswords no

# 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 internal-sftp #/usr/lib/openssh/sftp-server

# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

Match User sftpuser #group sftponly
ChrootDirectory /media/Backups/ftp
X11Forwarding yes
AllowTcpForwarding yes 
ForceCommand internal-sftp

The ssh -v laptop command outputs:

OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /home/malapradej/.ssh/config
debug1: /home/malapradej/.ssh/config line 1: Applying options for laptop
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to [] port 22.
debug1: Connection established.
debug1: identity file /home/malapradej/.ssh/id_rsa type -1
debug1: identity file /home/malapradej/.ssh/id_rsa-cert type -1
debug1: identity file /home/malapradej/.ssh/id_dsa type -1
debug1: identity file /home/malapradej/.ssh/id_dsa-cert type -1
debug1: identity file /home/malapradej/.ssh/id_ecdsa type -1
debug1: identity file /home/malapradej/.ssh/id_ecdsa-cert type -1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 zlib@openssh.com
debug1: kex: client->server aes128-ctr hmac-md5 zlib@openssh.com
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 1e:f2:57:81:28:8a:12:d3:7e:2d:04:c2:82:4f:43:72
debug1: Found key in /home/malapradej/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/malapradej/.ssh/id_rsa
debug1: Trying private key: /home/malapradej/.ssh/id_dsa
debug1: Trying private key: /home/malapradej/.ssh/id_ecdsa
debug1: No more authentication methods to try.
Permission denied (publickey).
share|improve this question
Please clarify how you are trying to connect the two: ssh? Also, what is the effect, an error message (if any) will help. –  crafter Sep 8 '13 at 20:25
hi crafter. Yes using ssh. I added the full error log above. –  Jacques MALAPRADE Sep 8 '13 at 20:29
Can you clarify which direction you are trying to connect (desktop to laptop?) and which sshd_config file you have posted? –  steeldriver Sep 8 '13 at 20:48
Check your permissions in .ssh. Try 700 for .ssh. 600 for .ssh/* . Also check who created them : you or root. –  crafter Sep 8 '13 at 20:48
the connection was from desktop to laptop and the sshd_config file is for the desktop. –  Jacques MALAPRADE Sep 9 '13 at 7:34

1 Answer 1

Thnx for the help. That solved it. My permissions needed to be set as 700 for .ssh. 600 for .ssh/, making sure you do it on both machines. Also change the ownership of .ssh/. and .ssh/ to the user from root, otherwise any information in the config file will not be accessible to the user.

sudo chmod 700 ~/.ssh/
sudo chmod 600 ~/.ssh/*
sudo chown -R User ~/.ssh/
sudo chgrp -R User ~/.ssh/

where User is the user name. This worked for me.

share|improve this answer
+1 for posting your solution. –  crafter Sep 9 '13 at 10:13
+1. Another scenario where this answer is useful: you mistakenly copied authorized_keys file on the server from one user to another to speed up the process. –  valk Mar 7 at 8:09

Your Answer


