ssh-keygen problem

Question

I have configured the ssh-key using keygen for password less authenticaton as from the following link http://rcsg-gsir.imsb-dsgi.nrc-cnrc.gc.ca/documents/internet/node31.html nO matter what i do this keeps on asking password.i have googled a lot for this also i have set the permissions to on .ssh to 700 and authorized_keys file to 600.I have changed the following in /etc/ssh/sshd_config file

 ChallengeResponseAuthentication no
 PasswordAuthentication no

restarted ssh,restared the system ,checked ssh-agent pid and it is running.This is still asking for the password please let me know if any one can throw some light on it..

ssh -v output

 OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
 debug1: Reading configuration data /etc/ssh/ssh_config
 debug1: Applying options for *
 debug1: Connecting to 174.3.16.182 [174.3.16.182] port 22.
 debug1: Connection established.
 debug1: permanently_set_uid: 0/0
 debug1: identity file /root/.ssh/identity type -1
 debug1: identity file /root/.ssh/id_rsa type -1
 debug1: identity file /root/.ssh/id_dsa type 2
 debug1: loaded 3 keys
 debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
 debug1: match: OpenSSH_4.3 pat OpenSSH*
 debug1: Enabling compatibility mode for protocol 2.0
 debug1: Local version string SSH-2.0-OpenSSH_4.3
 debug1: SSH2_MSG_KEXINIT sent
 debug1: SSH2_MSG_KEXINIT received
 debug1: kex: server->client aes128-cbc hmac-md5 none
 debug1: kex: client->server aes128-cbc hmac-md5 none
 debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
 debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
 debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
 The authenticity of host '174.3.16.182 (174.3.16.182)' can't be established.
 RSA key fingerprint is ca:85:11:08:550:65:7b:8b:5c:73:62:94:38:59:65:.
 Are you sure you want to continue connecting (yes/no)? yes
 Warning: Permanently added '174.3.16.182' (RSA) to the list of known hosts.
 debug1: ssh_rsa_verify: signature correct
 debug1: SSH2_MSG_NEWKEYS sent
 debug1: expecting SSH2_MSG_NEWKEYS
 debug1: SSH2_MSG_NEWKEYS received
 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: Trying private key: /root/.ssh/identity
 debug1: Trying private key: /root/.ssh/id_rsa
 debug1: Offering public key: /root/.ssh/id_dsa
 debug1: Authentications that can continue: publickey,password
 debug1: Next authentication method: password
 root@174.3.16.182's password:

Edit:This is sshd_config file on the remote machine

     #       $OpenBSD: sshd_config,v 1.73 2005/12/06 22:38:28 reyk Exp $

     # This is the sshd server system-wide configuration file.  See
     # sshd_config(5) for more information.

     # This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin

     # The strategy used for options in the default sshd_config shipped with
     # OpenSSH is to specify options with their default value where
     # possible, but leave them commented.  Uncommented options change a
     # default value.

     #Port 22
     #Protocol 2,1
     Protocol 2
     #AddressFamily any
     #ListenAddress 0.0.0.0
     #ListenAddress ::

     # HostKey for protocol version 1
     #HostKey /etc/ssh/ssh_host_key
     # HostKeys for protocol version 2
     #HostKey /etc/ssh/ssh_host_rsa_key
     #HostKey /etc/ssh/ssh_host_dsa_key

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

     # Logging
     # obsoletes QuietMode and FascistLogging
     #SyslogFacility AUTH
     SyslogFacility AUTHPRIV
     #LogLevel INFO

     # Authentication:

     #LoginGraceTime 2m
     #PermitRootLogin yes
     #StrictModes yes
     #MaxAuthTries 6
     RSAAuthentication yes
     PubkeyAuthentication yes
     #AuthorizedKeysFile     /root/.ssh/authorized_keys

     # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
     #RhostsRSAAuthentication no
     # similar for protocol version 2
     #HostbasedAuthentication no
     # Change to yes if you don't trust ~/.ssh/known_hosts for
     # RhostsRSAAuthentication and HostbasedAuthentication
     #IgnoreUserKnownHosts no
     # Don't read the user's ~/.rhosts and ~/.shosts files
     #IgnoreRhosts yes

     # To disable tunneled clear text passwords, change to no here!
     #PasswordAuthentication yes
     #PermitEmptyPasswords no
     PasswordAuthentication yes

     # Change to no to disable s/key passwords
     #ChallengeResponseAuthentication yes
     ChallengeResponseAuthentication no

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

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

     # Accept locale-related environment variables
     AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
     AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
     AcceptEnv LC_IDENTIFICATION LC_ALL
     #AllowTcpForwarding yes
     #GatewayPorts no
     #X11Forwarding no
     X11Forwarding yes
     #X11DisplayOffset 10
     #X11UseLocalhost yes
     #PrintMotd yes
     #PrintLastLog yes
     #TCPKeepAlive yes
     #UseLogin no
     #UsePrivilegeSeparation yes
     #PermitUserEnvironment no
     #Compression delayed
     #ClientAliveInterval 0
     #ClientAliveCountMax 3
     #ShowPatchLevel no
     #UseDNS yes
     #PidFile /var/run/sshd.pid
     #MaxStartups 10
     #PermitTunnel no
     #ChrootDirectory none

     # no default banner path
     #Banner /some/path

     # override default of no subsystems
     Subsystem       sftp    /usr/libexec/openssh/sftp-server

This is the sshd_config file on which the key is generated

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

  # Accept locale-related environment variables
  AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
  AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
  AcceptEnv LC_IDENTIFICATION LC_ALL
  #AllowTcpForwarding yes
  #GatewayPorts no
  #X11Forwarding no
  X11Forwarding yes
  #X11DisplayOffset 10
  #X11UseLocalhost yes
  #PrintMotd yes
  #PrintLastLog yes
  #TCPKeepAlive yes
  #UseLogin no
  #UsePrivilegeSeparation yes
  #PermitUserEnvironment no
  #Compression delayed
  #ClientAliveInterval 0
  #ClientAliveCountMax 3
  #ShowPatchLevel no
  #UseDNS yes
  #PidFile /var/run/sshd.pid
  #MaxStartups 10
  #PermitTunnel no

  # no default banner path
  #Banner /some/path

  # override default of no subsystems
  Subsystem       sftp    /usr/libexec/openssh/sftp-server

How did you generate your key-pair? You may have a problem in the generated public/private key-pair. Can you please paste the command? — Khaled, Nov 11 '10 at 10:30
@khaled: the command is ssh-keygen -t rsa as described in the link mentioned — Rajeev, Nov 11 '10 at 10:35
As Janne says, could you post your sshd_config file? Another way to get good diagnostics server-side in my experience is to run a temporary sshd non-detached and logging on another port, eg "sshd -d -p 2222", ensure that port 2222 isn't firewalled, and try sshing in remotely with "ssh server -p 2222". The server, in my experience, tends to log a lot of useful information that the client doesn't have access to. — MadHatter, Nov 11 '10 at 10:55
@Mad Hatter: i have disabled SE Linux and firewall.I will post the sshd_config on which the key is generated now — Rajeev, Nov 11 '10 at 10:58
Hang on a minute, you originally said that you changed "PasswordAuthentication no", but in the config file you posted, it says "PasswordAuthentication yes". Are you sure that's the right config file? — MadHatter, Nov 11 '10 at 10:59
@MadHatter: it is the correct file and PasswordAuthentication is yes.If i say no it wouldnt let me login — Rajeev, Nov 11 '10 at 11:22
ok, that's fair enough. have you tried running a potted debugging version of sshd for a single failed connection, as i describe four comments above? Your sshd_config looks OK to me, so some debug output would be very useful! — MadHatter, Nov 11 '10 at 11:49
Let me know what debug info you need to see..i tried running the above commands as u said i get a message as connection refused.The firewalls are disable on both sides now — Rajeev, Nov 11 '10 at 11:58
SO: you ran on server "/usr/sbin/sshd -d -p 2222" as root, you are sure that port 2222 on the server isn't firewalled from the client, and on the client you ran "ssh root@server -p 2222"? and got "connection refused"? if we get this working, it's the sshD output i want to see, not the ssh output. — MadHatter, Nov 11 '10 at 12:13
I cannot run it on the client since client is a remote web server and my server is behind a firewall — Rajeev, Nov 11 '10 at 13:41
Cannot run what on the client? ssh to the server as root? I thought that's what you were trying to run in the beginning? — MadHatter, Nov 11 '10 at 13:46
what i said was i cannot ssh to server from client.But can do so from server to client — Rajeev, Nov 11 '10 at 14:39
let me be clear about my language. we're testing ssh. the client is the box you ssh FROM, the one on which you run "ssh". the server is the box you ssh TO, the one which is running "sshd". what the boxes do the rest of the time, whether one is a web server or the other is an LVS client, i don't care. we're talking about ssh here, so that determines which one is server and which is client. that given, can you go back to my test of four comments ago, and run it? — MadHatter, Nov 11 '10 at 15:05

Janne Pikkarainen · Accepted Answer · 2010-11-11T10:58:06.377

4

The definitely easiest way to setup the ssh key is to use command

ssh-copy-id -i ~/.ssh/id_rsa.pub account@yourserver.com

If even that fails, then you have something odd in your sshd_config we need to take care of.

EDIT: So it was something wrong with your sshd_config, after all.

Change this:

 #PermitRootLogin yes

to be

 PermitRootLogin without-password

So only key authentication for root is allowed. Or, if you want to run only specific commands, forced-commands-only would be even better option, but before going that far, make this work with the without-password option.

Anyway, after that change restart your sshd and see how things just start to work!

edited Nov 11 '10 at 10:58

answered Nov 11 '10 at 10:05

Janne Pikkarainen

31,852
4
58
81

@Janne Pikkarainen:how does it matter i had ssh to the machine and copied the key manually.Does it matter in any way.Thanks.Let me know what info do u need on sshd_config file – Rajeev Nov 11 '10 at 10:06
I could copy the key from your above command but still the password is being prompted for.. – Rajeev Nov 11 '10 at 10:08
Doesn't matter in any other than ssh-copy-id removes the potential PEBKAC barrier. :-) So, since your password is still being prompted, could we take a look at your sshd_config? – Janne Pikkarainen Nov 11 '10 at 10:10
This should be done on the remote machine rit?? – Rajeev Nov 11 '10 at 11:07
Yes, of course the server side. :-) Or remote, whatever 'ya call it. – Janne Pikkarainen Nov 11 '10 at 11:09
No luck as yet..that almost made me not to login at all.Luckily i had ssh sessions opened that saved me.Any other go..... – Rajeev Nov 11 '10 at 11:19
Don't you any other account for use than root? But at this point you are doing something very odd completely wrong ... not sure, what. Perhaps you copied something like ~/.ssh/id_rsa as a key to another machine instead of ~/.ssh/id_rsa.pub? Is there something in the server logs for you to read? – Janne Pikkarainen Nov 11 '10 at 11:25
There is but i need to login as root to the remote machine to do some specific operations.I copied the id_rsa.pub file only – Rajeev Nov 11 '10 at 11:27
Yes, but if you suddenly are unable to connect as root, you could always use your normal user account for ssh and then just `su -` yourself to root. That's actually the traditional recommended way - do not allow root logins, always use a normal account and then gain the root if needed. – Janne Pikkarainen Nov 11 '10 at 11:30
k.so u r telling me that i will try the above steps on another user account?But how does it matter i have set this up as root on another machine and it works fine – Rajeev Nov 11 '10 at 11:32
No, you don't have to repeat the steps as another user. :) That's just another way to get back in if the root user really stops working. You see, sshd tends to be very strict when it comes to root logins due the security reasons. Still I don't get what's wrong, since all you should need would be that PermitRootLogin directive and a correct ssh-key for this thing to work. What does `getenforce` return on your server? – Janne Pikkarainen Nov 11 '10 at 11:34
It returns disabled.. – Rajeev Nov 11 '10 at 11:36
definitely for effort! +1 – d-_-b Dec 20 '10 at 02:11

score 0 · Answer 2 · answered Nov 11 '10 at 10:09

0

First and foremost, are you certain you are allowed to ssh into root? (hint: check your sshd_config file on the server).

Secondly, are you by any chance logged in as a user and using sudo or some other mean to impersonate somebody else? Perhaps you are just launching ssh from the wrong $USER!

answered Nov 11 '10 at 10:09

lorenzog

2,799
3
20
24

@lorenzog:i have logged in as root user only.My machine is RHEL5 and the key i amtring to setup is on CentOs – Rajeev Nov 11 '10 at 10:11
You are not allowed to login as root unless you uncomment the `#PermitRootLogin yes` clause in the `sshd_config` file on the destination machine. – lorenzog Nov 11 '10 at 11:57
@lorenzog: i have done it now.. – Rajeev Nov 11 '10 at 12:08
And...? Does it work? – lorenzog Nov 11 '10 at 12:15
No...................... – Rajeev Nov 11 '10 at 13:31
did you restart the ssh daemon after modifying the file? – lorenzog Nov 11 '10 at 14:10
yup i did so.... – Rajeev Nov 11 '10 at 14:38
Ok. now are you certain the key is valid? I.e. did you try copying it on another machine and ssh'ing into it? If that does not work perhaps the copying process added some extra lines or chars that screwed things up. Also, if you copy-pasted the key in an editor, beware of newline characters. If the key works on another machine I have no more clue sorry. – lorenzog Nov 11 '10 at 15:16
i used ssh-copy-id command that should not be a problem here – Rajeev Nov 11 '10 at 15:48
Try scp'ing the key or another method. – lorenzog Nov 11 '10 at 16:30
i tried thats not an issue.See the ssh -v output in my question..... – Rajeev Nov 11 '10 at 17:19

score 0 · Answer 3 · answered Nov 11 '10 at 10:56

0

Try increasing the size of the generated key. Use the following:

ssh-keygen -t rsa -b 4096

Then, copy the public key to the remote machine (to .ssh/authorized_keys).

answered Nov 11 '10 at 10:56

Khaled

36,533
8
72
99

i tried increasing the key size.no luck as yet – Rajeev Nov 11 '10 at 11:04
Check the copied file name and permission. – Khaled Nov 11 '10 at 11:06
I did check its all the same – Rajeev Nov 11 '10 at 15:48

score 0 · Answer 4 · answered Nov 12 '10 at 02:32

When you do an ssh-keygen you are asked for a passphrase, or 'enter' for none. I always hit 'enter'. When the keys (public and private) are generated, copy the public one to the machine in question. Then do a 'cat'key.pub (or whatever was generated) >> .ssh/authorized_keys. I routinely ssh from one machine to another without being prompted for passwords. I run centos5.5, debian, and slackware.

Alan

ssh-keygen problem

4 Answers4