LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)
-   -   SSHD Issue. (https://www.linuxquestions.org/questions/linux-software-2/sshd-issue-868179/)

MaverickApollo 03-12-2011 02:29 PM

SSHD Issue.
 
I've got a slight issue with logging into my server using public keys.

It was working fine, until I had to rebuild my desktop machine. I had the key copied to the server, and passwordless logins where fine.

However now I have rebuilt my desktop, I cant get to the login.

So heres whats happend.

Rebuilt id_rsa.pub, server will not allow login. Remove id_rsa.pub and the server allows password based login.

On the server, removed authorized_keys and known_hosts. makes no difference. Server still disallows keyfile, but will allow password when id_rsa is not present on the client.

Heres a -v of the login chat with keyfile

Code:

michael@eve:~$ ssh -v server
OpenSSH_5.5p1 Debian-6, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to server [ser.ver.ip] port 22.
debug1: Connection established.
debug1: identity file /home/michael/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/michael/.ssh/id_rsa-cert type -1
debug1: identity file /home/michael/.ssh/id_dsa type -1
debug1: identity file /home/michael/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6
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: 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
debug1: Host 'host' is known and matches the RSA host key.
debug1: Found key in /home/michael/.ssh/known_hosts:1
debug1: ssh_rsa_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 public key: /home/michael/.ssh/id_rsa
Received disconnect from ser.ver.ip: 2: Too many authentication failures for michael

And without

Code:

michael@eve:~/.ssh$ ssh -v server
OpenSSH_5.5p1 Debian-6, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to server [ser.ver.ip] port 22.
debug1: Connection established.
debug1: identity file /home/michael/.ssh/id_rsa type -1
debug1: identity file /home/michael/.ssh/id_rsa-cert type -1
debug1: identity file /home/michael/.ssh/id_dsa type -1
debug1: identity file /home/michael/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6
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: 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
debug1: Host 'server' is known and matches the RSA host key.
debug1: Found key in /home/michael/.ssh/known_hosts:1
debug1: ssh_rsa_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: Trying private key: /home/michael/.ssh/id_rsa
debug1: Trying private key: /home/michael/.ssh/id_dsa
debug1: Next authentication method: password
michael@server's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_GB.UTF-8
Linux s15433632 2.6.18-028stab070.4 #1 SMP Tue Aug 17 18:32:47 MSD 2010 x86_64

So, is there anyway of getting the server to forget the previous keys, it is remembering, As previousily said, I have completly removed the contents of ~/.ssh/ on both the clients and the server.

druuna 03-13-2011 05:08 AM

Hi,

First that comes to mind: Are the permissions on ~/.ssh directory and the files in ~/.ssh correct?

Permissions for ~/.ssh should be 700 (owner read/write/execute, group and world no permissions). The authorized_keys file should be 600 (owner read/write, rest no permissions).

Hope this helps.

MaverickApollo 03-13-2011 05:21 AM

drwx------ 2 michael michael 4096 Mar 12 20:20 .ssh

All permissions are fine, it is 700 through the entire ~/.ssh

Could there be another file the server is looking in, and getting the old key?

druuna 03-13-2011 05:34 AM

Hi,
Quote:

Originally Posted by MaverickApollo (Post 4288921)
All permissions are fine, it is 700 through the entire ~/.ssh

I hope that is a typo.... The ~/.ssh dir should be 700, _not_ the content of that directory. As stated before, authorized_keys should be 600.

Quote:

Could there be another file the server is looking in, and getting the old key?
If you deleted .ssh dir and content and started over: No.

Although I only encountered it once myself (still no clue why the original entry did not work), you can try the following as well: Edit your /etc/sshd/sshd_config file ans change this line AuthorizedKeysFile .ssh/authorized_keys into this AuthorizedKeysFile /home/%u/.ssh/authorized_keys

Hope this helps.

EDIT

Do restart the sshd server when editing the sshd_config file....

/EDIT

MaverickApollo 03-13-2011 05:42 AM

I tried your suggestion of changing the AuthorizedKeyfile location, and restarted sshd.

I'm still getting "Too many authentication failures" when i generate a keyfile.

druuna 03-13-2011 05:51 AM

Hi,
Quote:

Originally Posted by MaverickApollo (Post 4288934)
I tried your suggestion of changing the AuthorizedKeyfile location, and restarted sshd.

I'm still getting "Too many authentication failures" when i generate a keyfile.

That info wasn't included before. Is this new or did you get this message all along??

Also: How about the possible typo I mentioned??

Anyway: I would suggest completely removing the ~/.ssh directories on both machines and follow the following guide: SSH with Keys in a console window.

BTW: Put the original AuthorizedKeysFile line back into the sshd_config file.

Hope this helps.

MaverickApollo 03-13-2011 05:58 AM

Sorry, yes, thats whats it has been doing all along.

The typo was. the directory contents are 600, but have both been removed on client and server, and all that exists is known_hosts.

So to recap, as soon as I run ssh-keygen -t rsa I get the login fail. If i remove the keyfile fromthe client, I get in via password. As soon as I regenerate the keyfile (Even with empty ~/.ssh on the server) it will not allow login.

druuna 03-13-2011 06:21 AM

Did you try my other suggestion?

MaverickApollo 03-13-2011 06:31 AM

Removing both client and server ~/.ssh directorys and following your link tutorial?

Yes, I have removed both ~.ssh several times. But as soon as I create the id_rsa.pub the server will not allow login. So I cant send the new keyfile.

druuna 03-13-2011 07:05 AM

Hi,

What happens when you try logging in (password-less) after the following command: ssh-add -D

You can also try increasing the MaxAuthTries value in /etc/ssh/sshd_config (needs a sshd restart).

Hope this helps.

MaverickApollo 03-13-2011 07:11 AM

Many Thanks for all your help Druuna.

I increased the MaxAuthTries, and now instead of rejecting the keyfile, it rejects it and moves on to the next auth meathod, which is password.

I do feel slightly stupid for not realising this, and again, thanks for your help and patience :)

Can now copy id via ssh-copy-id -i ~/.ssh/id_rsa.pub username@remote_host

druuna 03-13-2011 07:12 AM

You're welcome :)

Can you put up the [SOLVED] tag (first post -> Thread Tools)


All times are GMT -5. The time now is 02:06 PM.