ssh without password

[ANDREA_6]

Hello,
i installed a pubblic key on my client (redhat)
with "ssh-keygen -t rsa".

On my server (suse), i created the file /root/.ssh/authorized_keys
using /root/.ssh/id_rsa.pub (of the client).

I added on /etc/sshd_config (of the server) "PermitLogin yes" and "StrictModes no"

Then i restarted sshd (on the server).

BUT USING SSH IT STILL ASK ME TO INSERT PASSWORD...

I did the same operation between 2 redhat server and it works fine... but between redhat and suse it still ask me to insert password..

Is there something else to change in sshd_config?

Please help me..
Best regards,Andrea.

[ANDREA_6]

Sorry.. a little mistake..

The client is SUSE and the server is REDHAT.

[Sergejs Svitnevs · Accepted solution]

You should distribute the private key to your authorized client. Put the private key (id_rsa) in the $HOME/.ssh/on the source machine (RedHat).

Regards,
Sergejs

[ANDREA_6]

I did it.. but it still ask me to insert password.. any idea?

[VEL_1]

Check the permission for authorized_keys file. It should be 755.

I not working still, run in debug mode.

[ANDREA_6]

The permissions were correct..

[VEL_1]

Try to run the sshd in debug mode. This will give the exact error message.

[Sergejs Svitnevs]

Try to run ssh on the client in verbose mode (ssh -v -v _ and sshd on the server in debug mode (sshd -d -d). Then check your outputs for errors.

Regards,
Sergejs

[ANDREA_6]

Ihe error is "permission denied"

[ANDREA_6]

THIS IS -v OUTPUT:

OpenSSH_2.9p1, SSH protocols 1.5/2.0, OpenSSL 0x0090601f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 0 geteuid 0 anon 1
debug1: Connecting to 130.1.1.14 [130.1.1.14] port 22.
debug1: temporarily_use_uid: 0/0 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 0/0 (e=0)
debug1: restore_uid
debug1: Connection established.
debug1: read PEM private key done: type DSA
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 -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.6.1p2
debug1: match: OpenSSH_3.6.1p2 pat ^OpenSSH
debug1: Local version string SSH-1.5-OpenSSH_2.9p1
debug1: Waiting for server public key.
debug1: Received server public key (768 bits) and host key (1024 bits).
debug1: Host '130.1.1.14' is known and matches the RSA1 host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: Encryption type: 3des
debug1: Sent encrypted session key.
debug1: Installing crc compensation attack detector.
debug1: Received encrypted confirmation.
debug1: Doing password authentication.

[ANDREA_6]

sshd -d (on the server)

debug2: read_server_config: filename /etc/ssh/sshd_config
debug1: sshd version OpenSSH_3.6.1p2
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 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.

[Denver Osborn]

when you're troubleshooting ssh to use public/private key pair for auth, use 'ssh -vvv -o PreferredAuthentications=public' option. This might help.


I would also double check a few params in the sshd_config file.

PermitRootLogin yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys


To me, it seems like there is something not enabled on the server side.... like PubkeyAuth.

Hope this helps,
-denver

[Denver Osborn]

Also, at the time of the failure... look at the syslog for sshd messages. If there is a permissions problem with the suse's root ~/.ssh there should be something logged on the server side.

I also noticed your ssh debug output on the client didn't offer the private key either. Since you stated it works fine between RH client to RH server but fails from RH client to SuSE serve, I'd look at the sshd_config on the SuSE box. What's different between the RH server and SuSE server's sshd_config file?

-denver

[Dave Falloon]

Is it just asking for the passphrase for your private key?

Try using ssh-agent to hold the key for a session, it means you'll have to have the agent be the parent to whatever process you are running, ie. if you want to have password less ssh sessions anytime you open an Xterm, you'll want ssh-agent to be the parent process of your xsession, that way you only have to run ssh-add once for the key to be loaded for all your sessions.

or is the problem that ssh is reverting to password auth?

--Dave

[TwoProc]

Andrea, from what I've seen - the file name is "authorized_keys2" for an rsa key. Try that out and see if it fixes your problem. Also, I've had lots of luck tightening down on the permissions for .ssh directory and all files within with no loss of connectivity. Try ratcheting down the security after you've got it working...

[Rene Sasse]

pls have also a look into the /var/log/messages, /var/log/secure and auth.log

[Andrew Cowan]

When you installed SSH is it running as user sshd, if so does it have permissions to your home directory?

The other common problem when keys are rejected is if there are line breaks within the keystring in "authorized_hosts". Check this by editing the file in vi and running the cursor along the line, or pressing $ to find the end.

[Gerard_22]

I had a "permssion denied" problem recently

The solution was

--> Directory .ssh must be
drwx------

--> file .ssh/authorized_keys
must be -rw-------

Gérar

[Andrew Cowan]

This is pretty much what I was asking here to check. You can prove this by setting "strictmode no" in the sshd_config and restarting the daemon.

[ANDREA_6]

Thank's a lot,
i solved the problem.

I changed my configurations in sshd_config using only ssh 2...
"Protocol 2"

At the beginning it was configured to use protocol 2 and 1.. but the network is very slow..
It's possible that without an immediate answer, the client tryed to use ssh1.. and maybe it doesn't work fine because the client have an old versin of ssh..

Best regards,Andrea.