SSH Server refused key

[dehein]

Hi i wanted to install a new version of Raspbian. Set everything up. Latest updates and so on.
I use a Windows machine to ssh via putty.
For this purpose i created a rsa key with puttygen. Copied the key from the field after creating. To just copy it into my authorized_keys file.
Here should be no problem it is the normal way of doing it. I am not using like others the save public file and would have to remove the first two and the last line and put something like rsa-**** infront. It already stands there.

So the fileformat should be normal.
In etc/ssh/sshd_config i removed the # infront of

Code: Select all

AuthorizedKeysFile    %h/.ssh/authorized_keys

I also had the permissions correct with

Code: Select all

sudo chmod 700 ~/.ssh 
sudo nano ~/.ssh/authorized_keys  
sudo chmod 600 ~/.ssh/authorized_keys 
sudo service ssh restart

But always after closing the connection and connecting again the only thing that happens is:
Server refused key.
The output of /var/log/auth.log is

Code: Select all

May 30 18:39:48 raspberrypi sshd[2836]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.2.104  user=pi
May 30 18:39:53 raspberrypi sshd[2836]: Accepted password for pi from 192.168.2.104 port 59151 ssh2
May 30 18:39:53 raspberrypi sshd[2836]: pam_unix(sshd:session): session opened for user pi by (uid=0)
May 30 18:39:57 raspberrypi sudo: pam_unix(sudo:session): session closed for user root

So i sit here for the hole day and have not found a solution.
Help appreciated.

[pnelsonsr]

What does /etc/ssh/sshd_config look like? The line that might matter is:
#RSAAuthentication yes
Not sure if yes or no is the default. But you might try un-commenting it and restarting sshd.
Also you could use the verbose command line option to see if there is anything else that is happening.
Also you could tail the log /var/log/secure while doing the connection.

[dehein]

What does /etc/ssh/sshd_config look like? The line that might matter is:
#RSAAuthentication yes
Not sure if yes or no is the default. But you might try un-commenting it and restarting sshd.
Also you could use the verbose command line option to see if there is anything else that is happening.
Also you could tail the log /var/log/secure while doing the connection.

RSAAuthentication yes is uncommented.
How do i use the verbose command? I connect via Putty. I tried to log everything, but it only logs the input in the console.
How could i connect via commandline in windows8.
In the end i can still connect via entering the password, but before i remove this function for security reasons i want it to work.

[dehein]

I have finally managed it.
I will never generate a rsa key in putty again.
I just generated both on the desired system, don't need to copy it via putty ssh onto the desired server. I think maybe something like UTF-8 or such things messed it totally up.

Now it works.
Just used

Code: Select all

ssh-keygen -t rsa -b 4096

rename the file place it in the right directory and give the right permission. Finished. No more problems.

[jojopi]

One of the main benefits of asymmetric cryptography is that it avoids the need for a pre-existing secure channel between the parties over which to exchange a secret key. The public key can be exchanged over insecure channels and even published (and there is no need to chmod it). The private key never needs to be exchanged at all. It exists on only one system and is readable by only one user, and the only way the private key could be obtained by a third party is by compromise of that specific system.

Although you can also get a working configuration by copying the private key backwards from the target, or by sharing a private key between multiple hosts, you defeat the above advantage by doing so. Now the private key has existed on multiple systems and been copied between them. The number of ways that the key could eventually be compromised is greatly increased.

Most of all though, it does work fine to paste a key from PuTTYgen into authorized_keys. There should be no reason to resort to doing it backwards. There is also no particular reason that the private key should be any less likely to corrupt during the copy. If anything it is harder than copying a public key because the permissions are more critical.

From your original description it does sound that you found the correct format of the key. The key data is base64 encoded, so it is in a very safe subset of ASCII (except perhaps for the comment at the end, but that is ignored). I think the mostly likely corruption is that it gets truncated or wrapped during the paste. If the authorized_keys file contains only one key, then you can check it is valid with the command:

Code: Select all

ssh-keygen -lf ~/.ssh/authorized_keys