Hi there,

I am trying to use ssh without password. I had followed the following steps.

At Client:

Step:1
[ameya@localhost ameya]$ssh-keygen -t rsa

Step:2
[ameya@localhost ameya]$ssh -l ameya 172.19.32.248 mkdir -p .ssh

Step:3
[ameya@localhost ameya]$cat .ssh/id_rsa.pub | ssh -l user2 computer2 \>'cat >> .ssh/authorized_keys'

The documentation says that now it should work, but its not.

After that I also tried by changing the mode of .ssh & authorized_keys at the server end, to 700 and 600 respectively.

But still its noe working.

My debug mode log of the sshd is as follows:

[root@pc-p41215 root]# /usr/sbin/sshd -d -d
debug1: sshd version OpenSSH_3.5p1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
socket: Address family not supported by protocol
debug1: Bind to port 22 on 0.0.0.0.
Bind to port 22 on 0.0.0.0 failed: Address already in use.
Cannot bind any address.
[root@pc-p41215 root]#

And the snapshot of configuration file at /usr/sbin/sshd_config is :

#$OpenBSD: sshd_config,v 1.59 2002/09/25 11:17:16 markus 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

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

#ServerKeyBits 768


# Logging

#obsoletes QuietMode and FascistLogging
SyslogFacility AUTH
SyslogFacility AUTHPRIV
LogLevel

DEBUG


# Authentication:


#LoginGraceTime 120

#PermitRootLogin yes

#StrictModes yes



RSAAuthentication yes

PubkeyAuthentication yes

AUTHOrizedKeysFile .ssh/authorized_keys



# rhosts authentication should not be used

#RhostsAuthentication no

# 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/ssh_known_hosts
RhostsRSAAuthentication yes

# similar for protocol version 2
HostbasedAuthentication yes

# Change to yes if you don't trust ~/.ssh/known_hosts for

# RhostsRSAAuthentication and HostbasedAuthentication

#IgnoreUserKnownHosts no


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

#PasswordAuthentication yes

#PermitEmptyPasswords no


# Change to no to disable s/key passwords

#ChallengeResponseAuthentication yes


# Kerberos options

#KerberosAuthentication no

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes


#AFSTokenPassing no


# Kerberos TGT Passing only works with the AFS kaserver

#KerberosTgtPassing no


# Set this to 'yes' to enable PAM keyboard-interactive authentication

# Warning: enabling this may bypass the setting of 'PasswordAuthentication'
#PAMAuthenticationViaKbdInt no


#X11Forwarding no
X11Forwarding yes

#X11DisplayOffset 10

#X11UseLocalhost yes

#PrintMotd yes

#PrintLastLog yes

#KeepAlive yes

#UseLogin no

#UsePrivilegeSeparation yes

#PermitUserEnvironment no

#Compression yes


#MaxStartups 10

# no default banner path

#Banner /some/path

#VerifyReverseMapping no


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

Changes made in the config file:

1. Uncomment the RSAAuthentication yes.

2. Uncomment the PubkeyAuthentication yes

3. Uncomment the AUTHOrizedKeysFile .ssh/authorized_keys

But everything gone in vein.

Please suggest me what to do next.

Its really urgent..

Thanks in anticipation.

Regards

Amit

I think the Bind to port 22 on 0.0.0.0 failed: Address already in use error is because you have IP4 and IP6 running - binds to IP4 then can't bind to IP6 - not sure if this is causing the problem though.
Can you poet the output of your client ssh with -vv switch so we can see what it's trying to do.
Also worth checking there are no characters in the key file that shouldn't be there.

Also....I assume you can ssh using a password ok??

Hi Neil,

Thanks for your quick reply. Here is the output of the client ssh using -vv.

Yes I am able to connect using the password.

[ameya@localhost ameya]$ ssh -vv -l ameya 172.19.32.248
OpenSSH_4.2p1, OpenSSL 0.9.7a Feb 19 2003
debug1: Reading configuration data /usr/local/etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to 172.19.32.248 [172.19.32.248] port 22.
debug1: Connection established.
debug1: identity file /home/ameya/.ssh/identity type -1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/ameya/.ssh/id_rsa type 1
debug1: identity file /home/ameya/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.5p1
debug1: match: OpenSSH_3.5p1 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.2
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro
up14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1
28,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-c
tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1
28,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-c
tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro
up1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
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
debug2: dh_gen_key: priv key bits set: 116/256
debug2: bits set: 527/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '172.19.32.248' is known and matches the RSA host key.
debug1: Found key in /home/ameya/.ssh/known_hosts:1
debug2: bits set: 519/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/ameya/.ssh/identity ((nil))
debug2: key: /home/ameya/.ssh/id_rsa (0x808b3b8)
debug2: key: /home/ameya/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,password,keyboard-interacti
ve,hostbased
debug1: Next authentication method: publickey
debug1: Trying private key: /home/ameya/.ssh/identity
debug1: Offering public key: /home/ameya/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interacti
ve,hostbased
debug1: Trying private key: /home/ameya/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interacti
ve,hostbased
debug2: we did not send a packet, disable method
debug1: Next authentication method: password


Thanks & Regards

Amit Kanodia

This is a key problem - make sure the key in authorized_keys is correct - all on one line with no extra characters.
Did you specify the exat path to the private key on the client side (using -i)?

Please don't mark your posts as URGENT.. have a read here in this post about good thread titles: http://www.linuxquestions.org/questi...95#post1730795

Hi Neil,

Please guide me how to ensure that the right key has been generated.

I had used the following steps and commands.

# To Generate the key at the client side.
1. ssh-keygen -t rsa

# To create the dir .ssh at the remote server. After this command I had been
# prompted for the password after which it has been successful.
2. ssh -l ameya 172.19.32.248 mkdir -p .ssh


# To copy the public key at the remote host in the /home/.ssh dir.
# After this again it prompted for the password after which it had been successful.
3. cat .ssh/id_rsa.pub | ssh -l user2 computer2 \>'cat >> .ssh/authorized_keys'

I think in the step 3 you r specifying the -i option.

Please explain this.

Thanks & Regards

Amit Kanodia

Hi Amit

Can you ssh to the server and check authorized_keys is present and correct.
You specify the -i option on the client side eg. ssh -i /home/mykey user@server - it points to the location of the private key.

#PermitEmptyPasswords no

For empty password to work this needs to be set to yes as it is default no.
Not sure if you notice this in your sshd_config as it is not done here.

Check the permissions on the .ssh directory that contains the private key and of the private key itself. Looking a the ssh debug in your post yout key is called id_rsa.

chmod 700 .ssh
chmod 400 .ssh/id_rsa

The remote server may reject an attempt to log in with private key that is accessible to other users.

I notice from your debug that you allow hostbased authenication (rhosts, hosts.equiv). You really should disable this authentication mode since it's insecure. Better to depend on public/private keypairs. You should also not PermitEmptyPasswords; this will not stop you using a private key with no passphrase.

Regards,
Jimvin