Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

continued Not even able to login password-less.

$ ssh -v user@example.com
OpenSSH_6.0p1, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to example.com [XX.XX.XX.X1] port 22.
debug1: Connection established.
debug1: identity file /home/admin/.ssh/id_rsa type 1
debug1: identity file /home/admin/.ssh/id_rsa-cert type -1
debug1: identity file /home/admin/.ssh/id_dsa type -1
debug1: identity file /home/admin/.ssh/id_dsa-cert type -1
debug1: identity file /home/admin/.ssh/id_ecdsa type -1
debug1: identity file /home/admin/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1 Debian-7ubuntu1
debug1: match: OpenSSH_5.8p1 Debian-7ubuntu1 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 3b:81:30:2e:7a:c8:ca:51:7a:46:bb:50:cb:d3:a2:9b
debug1: Host 'example.com' is known and matches the ECDSA host key.
debug1: Found key in /home/admin/.ssh/known_hosts:2
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_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/admin/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/admin/.ssh/id_dsa
debug1: Trying private key: /home/admin/.ssh/id_ecdsa
debug1: Next authentication method: password
user@example.com's password:

sshd_config file on the site I want to connect but not able to.

# 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,
# 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 user

file permissions:


.ssh directory permission on the server example.com

drwx------ 2 user user      4096 2012-07-26 13:35 .ssh


permissions on the files of the .ssh file 

-rw------- 1 user user  398 2012-07-26 13:35 authorized_keys
-rw-r--r-- 1 user user 1428 2012-07-25 18:55 known_hosts
--------------------------------------------------------------------


pemissions in the files ~/.ssh and ~/.ssh/ files workstation 

drwx------+ 1 Admin  None     0 Jul  9 17:05 .ssh

-rw-------  1 admin None 1679 Jul  9 17:05 id_rsa
-rw-r--r--  1 admin None  398 Jul  9 17:05 id_rsa.pub
-rw-r--r--  1 admin None  383 Jul 26 13:35 known_hosts
share|improve this question

1 Answer 1

up vote 5 down vote accepted

Theoretical

I feel like I need to clarify some things that you may or may not understand about how SSH works:

In the context of SSH, Passwordless can refer to two things:

  • Authenticating over SSH without supplying a password over the wire; i.e., using public key authentication
  • Authenticating over SSH without supplying a password over the wire, and without using a password to protect the decryption of your private key

So there are three possible modes:

  1. Authenticate by directly supplying a password. No public/private keys are used.
  2. Authenticate by public/private keypair, but supply a password on your client machine to decrypt the private key and make it usable. This is done using ssh-agent. The private key decryption password is cached so that it is only supplied once for the duration of your login session; after that, the password will be saved in the ssh-agent.
  3. Authenticate by public/private keypair, but the keypair is not password-protected, so the user does not supply a password at all.

The second mode is the most secure. You can test this mode by creating a password-protected keypair, make sure ssh-agent is set up properly (as it is on modern Linux distros), and it should "just work": when you first login to an SSH server that uses your private key, you get a prompt to enter the password. Every time after that, until you logout, it "just works" with no prompt.

Practical

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/admin/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/admin/.ssh/id_dsa
debug1: Trying private key: /home/admin/.ssh/id_ecdsa
debug1: Next authentication method: password

Try the following:

  • Rename the known_hosts file to something else (like known_hosts.bak) on both the client and server

  • On the server, logged in as user, try

    chmod go-w ~/
    chmod 700 ~/.ssh
    chmod 600 ~/.ssh/authorized_keys

  • On the client, logged in as admin, try

    chmod 700 ~/
    chmod 700 ~/.ssh
    chmod 400 ~/.ssh/id_rsa chmod 400 ~/.ssh/id_rsa.pub
    #if the admin user doesn't have a group, create it and make it the admin user's primary group
    chown -R admin:admin ~/.ssh

  • Make darn sure that the contents of the client's ~/.ssh/id_rsa.pub (note, the .pub is critical) is in the server's ~/.ssh/authorized_keys on one line (with no linebreaks -- but don't confuse text editor wrapping and linebreaks; use cat ~/.ssh/authorized_keys to ensure you're viewing the file without wrapping), and that the contents of the client's ~/.ssh/id_rsa is not anywhere on the server, or indeed, anywhere but that one place on the client. Note: If you have accidentally put ~/.ssh/id_rsa (the private key) on the server, I highly recommend that you delete your keypair and create a new one, starting over from scratch. You'll have to put the new id_rsa.pub into the authorized_keys file.

  • ???

  • Profit!

share|improve this answer
    
Thanks for your response,I like the way you clarify, understanding the limitations of the questioner. I will try what you said, so I assume by now that nothing in the ssh -v verbose connection attempts, the sshd_config file seems to and the permissions chmod seemed to be wrong from your point of view as well. –  tough Jul 27 '12 at 16:22
    
Thanks a lot, It did not work at the beginning but later realised that restart of ssh server was required after the change of the path of the Authorizedfile location in ssh_config from known_keys. Following all your instructions worked for me. Use of Known_keys was a mistake as you suggested. –  tough Jul 31 '12 at 12:51

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.