82

I'm trying to setup ssh authentication with key files in stead of username/password. The client is a Windows box running PuTTY and the server is a Ubuntu 12.04 LTS server.

I downloaded puttygen.exe and had it generate a key pair. In /etc/ssh/sshd_config I have this line:

AuthorizedKeysFile %h/.ssh/authorized_keys

and on my client's public key file it says this:

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "[email protected]"
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAr3Qo6T5XU06ZigGOd3eKvfBhFLhg5kWv8lz6
qJ2G9XCbexlPQGanPhh+vcPkhor6+7OmB+WSdHeNO652kTofnauTKcTCbHjsT7cJ
GNrO8WVURRh4fabknUHPmauerWQZ6TgRPGaz0aucU+2C+DUo2SKVFDir1vb+4u83
[email protected]
---- END SSH2 PUBLIC KEY ----

I copied the part from "ssh-rsa AAA" to "[email protected]" and put that in the file ~/.ssh/authorized_keys on my server (in my own homefolder). In PuTTY under Connection > SSH > Auth I entered the path to the private key it generated on my client and saved the session settings.

I restarted the ssh server with

sudo service ssh restart

Now if I load the profile in PuTTY (I verified the private key is still in Connection > SSH > Auth and that the path is correct) and run the profile, it says

Server refused our key

I tried putting the public key in a file under the directory ./ssh/authorized_keys/ but that didn't help so I used ./ssh/authorized_keys as a file, pasting the key in it. I also tried generating a private/public key pair on the server, putting the public key in ./ssh/authorized_files and loading the private one in PuTTY on my client. Rebooting the server didn't help either.

I found that the error may be solved by putting the key in a place outside the user's home folder but that's only useful if the home folder is encrypted, which this one is not.

Also tried generating a 4096 bit key, thinking perhaps 1024 was too short.

How can I get this to work? Thanks!

EDIT:

Ok, /var/log/auth.log said:

sshd: Authentication refused: bad ownership or modes for directory /home/vorkbaard/.ssh

Google tells me ~/.ssh/ should be 700 and and ~/.ssh/authorized_keys should be 600, so I did that. Now /var/log/auth.log says:

sshd: error: key_read: uudecode AAAAB3N [etc etc etc until about 3/4 of my public key]
2
  • 2
    /var/log/auth.log helps a lot, thanks =) Aug 4, 2021 at 21:39
  • +1 for checking /var/log/auth.log. I had an unrelated problem, but checking that log file helped me solve it.
    – Richard
    Dec 2, 2021 at 1:03

17 Answers 17

128

Ok, it is fixed however I don't see how this is different from what I tried already.

What I did:

  • generate a key pair with puttygen.exe (length: 1024 bits)
  • load the private key in the PuTTY profile
  • enter the public key in ~/.ssh/authorized_keys in one line (ssh-rsa {your_public_key} with no more than once space between ssh-rsa and your key)
  • chmod 700 ~/.ssh
  • chmod 600 ~/.ssh/authorized_keys
  • chown $USER:$USER ~/.ssh -R
  • change /etc/ssh/sshd_config so it contains AuthorizedKeysFile %h/.ssh/authorized_keys
  • sudo service ssh restart

For troubleshooting do # tail -f /var/log/auth.log.

Thanks for your help!

20
  • 1
    Hmm, so what happened to that sshd: error: key_read: uudecode AAAAB3N error in auth.log?
    – Alaa Ali
    Jun 11, 2013 at 13:27
  • 1
    I haven't a clue, Alaa. Perhaps I made an error pasting the previous key string. Auth.log doesn't get any more entries now and key based authentication works flawlessly. My main problem was that I wasn't really sure about what needed to be done, making the how that much more difficult. So I don't know why but it works. Thanks again for your help :)
    – Forkbeard
    Jun 11, 2013 at 18:23
  • 1
    I would add chmod go-w ~/
    – CappY
    Oct 22, 2014 at 19:25
  • 1
    Figured out two main things in /etc/ssh/sshd_config: uncomment AuthorizedKeysFile line and line PubkeyAcceptedKeyTypes ssh-dss. Jan 19, 2018 at 8:27
  • 1
    This is the golden checklist. Go down this list and one of them should fix it. Usually its permissions or rather the folder isn't owned by the user. Its very picky about the permissions. The .ssh folder and the authorized_keys file need to match the permissions on the list (700 and 600 as listed). The user you are connecting with needs to own the folder. Remember its chown username:group ~/.ssh -R. -R does all subfolders and will blanket everything below.
    – G_Style
    Mar 28, 2018 at 14:00
34

I just encountered this problem. Despite having the config set correctly as is already mentioned in this thread (permissions on authorized_keys etc.), it turns out I had the public key in the wrong format. It was in the form of:

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "imported-openssh-key"
AAAAB3NzaC1yc2EAAAADAQABAAABAQDUoj0N3vuLpeviGvZTasGQ...
... lPmTrOfVTxI9wjax2JvKcyE0fiNMzXO7qiHJsQM9G9ZB4Lkf71kT
---- END SSH2 PUBLIC KEY ----

Which wasn't working. But got it working having it in the form:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDU.....j0N3vuLpeviGvZTasGQa1rcJiPXQMW7v3uurb+n94B9MQaaWR0odsg5DJQL92TNenOda5BO1nd08y6+sdLQmHXExTz6X8FzgoVsAkEl3RscxcxHUksiKA9JfTo38vQvG/bPxIHMCuSumCQVA1laf3rO/uOrkcB7iMWhaoi1/z6AbFtPzeh7xjGfInMWwtBI0CsHSRF73VWIxT26w0P+KjafCjSn/7vDO1bT8QHujSQelU/GqaVEvbbvPl1a7POVjKgHLNekolwRKfNeVEewcnmZaoqfHgOKlPmTrOfVTxI9wjax2JvKcyE0fiNMzXO7qiHJsQM9G9ZB4Lkf71kT UserName@HOSTNAME
6
  • 22
    You can use ssh-keygen -i -f filenameofwindowsformpub.key to transform the public key into the format understood by your OpenSSH server.
    – Black
    Dec 23, 2015 at 9:24
  • Yes, it worked for me! It has to be in a single line. Can't believe it was only that! Jul 20, 2016 at 4:19
  • 2
    HI kuraara I reckon the above instruction by @Black should be made prominent in the answer.
    – ekerner
    Mar 12, 2017 at 3:07
  • Can I add comment to OpenSSH server format? For human it is hard to tell what computer this key represent. Jan 8, 2018 at 12:08
  • When I follow the suggestion by @Black, there is no UserName@HOSTNAME at the end of the string. I don't know if that part matters.
    – arnoldbird
    Aug 6, 2018 at 12:33
13

I had to change permissions to home directory

chmod 700 ~
5
  • 2
    This worked for me as well (on AIX though). Feb 19, 2015 at 18:44
  • Worked for me on CentOS as well
    – Jaywalker
    Apr 11, 2018 at 9:58
  • Worked for me on Redhat! Group write access seems to be the specific issue. Still works for me if I leave group read permissions in place though: "chmod 740 ~".
    – Paul
    Mar 12, 2019 at 17:20
  • If you're willing to start over, I find it easiest to rm ~/.ssh on the target and on the client run ssh-copy-id -i <ssh_key_file> <login>@<target>. ssh-copy-id will create ~/.ssh on the target with all the correct permisions.
    – JS.
    Mar 26, 2021 at 19:52
  • I can't thank you enough, it took me one day and found your answer here.
    – Sahin
    Feb 11, 2022 at 13:46
10

the problem is that windows uses a different new line than linux, so when copying the key from windows to linux, there is a \n at the end of the line that you can not see on linux in the editor.

If you tail the /var/log/auth.log and try to login, the error is like:

sshd: error: key_read: uudecode AAAAB3N[....]==\n

If you change your key on windows so its in a single line without a new line at the end and copy it then to linux, it should work (did the trick for me).

1
  • this was my problem, but i didn't see anything in auth.log to suggest that was the case. frustrating...
    – Anthony
    Aug 12, 2016 at 13:49
8

I had to change the ~/.ssh directory permissions from 770 to 700 and the ~/.ssh/authorized_keys file permissions from 660 to 600.

For some reason removing group permissions fixed this issue for me.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
7

The ~/.ssh/authorized_keys file requires keys to be all on one line. If you added it across multiple lines as in your paste above, try joining the lines.

2
  • Thanks, that makes sense and now I understand why it is a file, not a directory. However it didn't help.
    – Forkbeard
    Jun 11, 2013 at 12:07
  • 5
    for anyone who may be confused by this, what he means is each key itself has to be on a single line, but different keys need to be on different lines.
    – Anthony
    Aug 12, 2016 at 13:50
4

Here's what worked for me:

In puttygen, after you've generated your keys, make sure that you copy and paste the information from the top field to go into your authorized_keys file. If you save your public key to your client machine, and then open it up, the text is different from the text at the top of the puttygen screen. Again, make sure that you copy and paste the text from the TOP of the puttygen screen (after you've created your keys) into your authorized_keys file which should be located in ~/.ssh.

1
  • this actually fixed the problem. i dont get why if you click the save the public key why it doesnt save the proper format.
    – luky
    Sep 29, 2018 at 12:16
2

Sometimes it can be a problem associated with having the public key not on one line, so this approach seems to solve it:

echo 'the content of the public key' >> /root/.ssh/authorized_keys
1

In addition to all the above answers, make sure you copy and paste the key from puttygen correctly!

If you just double-click on the bulk of the key string to select it, you may not get the entire string, because the text box splits lines on some characters, like +, such that you don't select the text after the + character (which you can't see because the text box is too small). Be sure to select the entire string manually, from the ssh-rsa to the very end of the text box.

1

for me the problem was i'd created ~/.ssh/authorized_keys using root so root owned. I had to chown sshuser:sshuser ~/.ssh/authorized_keys then it started working

1

I too faced this error and solved it by changing the permissions of authorized_keys file to 600.

chmod 600 ~/.ssh/authorized_keys
1

Common error is that people uses text editor (like Vim) and paste the copied text before activating the "insert" (press +i in Vim before pasteing)

1

If you tried many ways inside .ssh and all failed, there is a possibility that you may need to chmod g-w ~ if you work in a multi-user enviornment.

0

In fact, I changed authorized_keys's permission to 644, then problem solved.

chmod 644 ~/.ssh/authorized_keys
0

to debug open ssh one can use:

sudo `which sshd` -p 2020 -Dd

it runs sshd on other port 2020. it runs sshd as a current program so output goes to screen. if closed it is closed.

then try to connect.

explanation:

  • `which sshd` - locates the sshd address , try execute which sshd see what it prints. when using back quotes it executes and returns the result in place.
  • -p 2020 - specifies port
  • -D - log to file
  • -d - log to screen

https://www.attachmate.com/documentation/rsit-unix-802/rsit-unix-guide/data/sshd_options_ap.htm

1
  • Could you expand upon this answer? What do the arguments entail? What is the command doing (for someone not experienced)? Apr 17, 2019 at 5:22
0

I had this issue on an AWS instance where I had moved /home from the root disk to a new separate disk at xvdf, for free space reasons.

There was nothing in the logs, not under auth or secure, or messages.

In the end I guessed SELinux was the culprit, and some googling lead me to audit2allow -w -a which showed a useful error when opening the user's authorized_keys file.

The fix was to run restorecon -R -v /home which relabelled things on the new disk and then selinux was happy to use the user's .ssh/authorized_keys file.

0

in my case (Ubuntu 22.04.1 LTS) changing /etc/ssh/sshd_config pubkeyacceptedkeytypes from ssh-rsa to +ssh-rsa worked

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .