Adding a public key to ~/.ssh/authorized_keys does not log me in automatically

Question

I added the public SSH key to the authorized_keys file. ssh localhost should log me in without asking for the password.

I did that and tried typing ssh localhost, but it still asks me to type in the password. Is there another setting that I have to go through to make it work?

I have followed the instructions for changing permissions:

Below is the result if I do ssh -v localhost.

debug1: Reading configuration data /home/john/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/john/.ssh/identity type 1
debug1: identity file /home/john/.ssh/id_rsa type -1
debug1: identity file /home/john/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu3
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
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
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /home/john/.ssh/known_hosts:12
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
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/john/.ssh/identity
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>

Then it asks for a passphase after the above log. Why isn't it logging me in without a password?

While it isn't the case here, if you're coming from Google and you're using an encrypted home directory, sshd won't be able to access it, and therefore won't be able to read your authorized_keys file. Here's a solution: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/362427/comments/12 — Daniel Schaffer, May 26 '13 at 19:38

score 1264 · Accepted Answer · edited Mar 14 '18 at 16:43

1264

You need to verify the permissions of the authorized_keys file and the folder / parent folders in which it is located.

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

For more information see this page.

You may also need to change/verify the permissions of your home directory to remove write access for the group and others.

chmod go-w ~

edited Mar 14 '18 at 16:43

Michael

41,989
11
82
128

answered Jun 16 '11 at 18:55

Teddy

18,357
2
30
42

8

Well something in the above worked, though isn't "chmod -R go-wrx foobar" rather dramatic? Why the need for recursive? – joachim Mar 23 '12 at 10:23
12

For the second part, it's not neccesary to make it recursive, just doing the `chmod go-wrx foobar` is enough. Doing it recursively could seriously bone some applications if you have some group or other access to files, especially if it's a web directory. – StingeyB Jul 18 '12 at 18:41
29

As mentioned on the OpenSSH FAQ, the user's home & .ssh directory only needs to write permission removed for group/other (so ``chmod go-w $HOME $HOME/.ssh`` will do the trick). Thus, permissions can be as 'open' as 755 for both directories, if you're so inclined. The simplest/least invasive commands are in the FAQ: http://www.openssh.org/faq.html#3.14 – davidjb May 08 '13 at 23:45
4

Why would didn't it work for me until I did `chmod 700 ~/.ssh && chmod 644 ~/.ssh/authorized_keys`? 600 didn't work where 644 did... – ficuscr Jan 09 '14 at 17:20
I noticed that this did not work on a windows PC with Cygwin because when I issue `chmod 0600 .ssh/id_rsa*`, the command goes, but for some reason Windows doesn't allow it, and my question about this got removed for some reason else where on the site about this. – FilBot3 May 20 '14 at 01:11
@Pred I don't know about Cygwin. – Teddy May 20 '14 at 12:33
@Teddy I don't remember where I found it, but I had to change ownership of the folder .ssh in Cygwin to be owned by Users, then I could chmod 0600 – FilBot3 May 20 '14 at 13:54
If anything, this made it worse... I got the error `Agent admitted failure to sign using the key.` until I restored the original permissions (`664`) – Wilf Jun 04 '14 at 21:39
1

Correct permissions may not be enough when SELinux is enforced. You might need to run `sudo restorecon -FRvv ~username/.ssh` – Dima Chubarov Oct 21 '14 at 14:29
Also note that I had to do this both on the client side running ssh program and server side running sshd program. Not either, but rather both. – enthusiasticgeek Dec 09 '14 at 16:49
FYI, I created a small script at https://github.com/centic9/generate-and-send-ssh-key which runs the necessary steps in one go and additionally ensures all the file/directory permissions which always caused me headaches... – centic Oct 07 '15 at 11:31
4

I also needed to `sudo chown -R {$USER}:{$USER} ~/.ssh/` because I had written the `authorized_keys` file as root. – Zane Jan 03 '16 at 01:19
1

If you happen to have a non-standard private key file name (e.g. anything other than `id_rsa`, `id_dsa`, or `id_ecdsa`), you may need to provide the `-i path-to-private-key-file` to your `ssh` command. – Rai Feb 07 '16 at 23:13
1

Sonofab... the chmod on the home directory was it for me. Who would have thought of that? Grr.. Thanks for the answer! – smendola Apr 20 '16 at 18:55
wow...in my case the permissions of the complete /home/user directory was set to 777...(wtf)...I had to remove write permissions for group and all - now it works like a charme, thanks :) – Bohne Apr 27 '16 at 11:48
1

@ficuscr - or others wondering why permissions 644 worked when 600 didn't... ssh tunneling requests *may* require that file to have 644 specifically. I've always connected ok with 600 with ssh keys with basic terminal connection to my server. But for fancier applications, port-forwarding, ProxyCommand, etc. you may need group or world read permissions on the file, or the remote file... or ... as needed. – bellasys Dec 17 '16 at 15:45

score 169 · Answer 2 · edited Aug 03 '20 at 21:02

169

SELinux can also cause authorized_keys not to work. Especially for root in CentOS 6 and 7. There isn't any need to disable it though.

Once you've verified your permissions are correct, you can fix this like so:

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
restorecon -R -v /root/.ssh

edited Aug 03 '20 at 21:02

Peter Mortensen

30,738
21
105
131

answered Feb 07 '14 at 19:42

Cole Stanfield

2,437
2
19
12

9

The `restorecon` is what you need after you have copied the files by hand, e.g. to a new hard drive. (You should probably run it on all files in this case. Could fix other odd problems.) – ospalh Sep 24 '15 at 07:58
Another happy camper here. This was my problem in RHEL 6.5 – Antonio Ortells Dec 19 '16 at 18:08
3

9/10 times, a "why isn't this working, it always works" issue is an selinux issue. – Andrew White Apr 10 '17 at 22:33
fixed the problem for me on 1and1 (1und1) server – musicman Dec 10 '17 at 14:18
Fixed for me on fedora 35 when migrating home to another hdd – MeetTitan Jan 01 '22 at 20:41

score 122 · Answer 3 · edited Aug 03 '20 at 21:16

Setting ssh authorized_keys seem to be simple, but it hides some traps I'm trying to figure.

-- SERVER --

In /etc/ssh/sshd_config, set passwordAuthentication yes to let the server temporarily accept password authentication

-- CLIENT --

consider Cygwin as Linux emulation and install & run OpenSSH

1. Generate private and public keys (client side) # ssh-keygen

Here pressing just Enter, you get default two files, "id_rsa" and "id_rsa.pub", in ~/.ssh/, but if you give a name_for_the_key, the generated files are saved in your current working directory.

2. Transfer the your_key.pub file to the target machine, ssh-copy-id user_name@host_name

If you didn't create a default key, this is the first step to go wrong ... you should use:

ssh-copy-id -i path/to/key_name.pub user_name@host_name

3. Logging ssh user_name@host_name will work only for the default id_rsa file, so here is the second trap. You need to do ssh -i path/to/key_name user@host

(Use ssh -v ... option to see what is happening.)

If the server still asks for a password then you gave something. To Enter passphrase: when you've created keys (so it's normal).

If ssh is not listening on the default port 22, you must use ssh -p port_nr.

-- SERVER -----

4. Modify file /etc/ssh/sshd_config to have

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  %h/.ssh/authorized_keys

(uncomment if case)

This tells ssh to accept file authorized_keys and look in the user home directory for the key_name sting written in the .ssh/authorized_keys file.

5 Set permissions on the target machine

chmod 755 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Also turn off pass authentication,

passwordAuthentication no

to close the gate to all ssh root/admin/....@your_domain attempts.

6. Ensure ownership and group ownership of all non-root home directories are appropriate.

chown -R ~ usernamehere
chgrp -R ~/.ssh/ user

===============================================

7. Consider the excellent http://www.fail2ban.org

8. Extra SSH tunnel to access a MySQL (bind = 127.0.0.1) server

Note that "just 4 security" is not just for security! SSH will ignore the file if it does not have restrictive permissions. — Navin, Oct 31 '14 at 05:54
I had no idea about `ssh-copy-id`! That step alone would make a great answer. — James Marble, Jul 07 '16 at 03:59
chmod 755 ~/.ssh instead of 700 that I see elsewhere seemed to do it — Jim W, Dec 02 '16 at 22:52
WOW... my issue was the "default naming" (Step 2). SSH does not pickup any files in ".ssh" ? this cost me some days... Thanks a lot! — Sunchezz, Jan 29 '21 at 23:11
`AuthorizedKeysFile %h/.ssh/authorized_keys` This line is important. Especially if you have managed to do something clever like tell it to ignore a user's authorized keys file for security. — Drazisil, Oct 23 '21 at 01:20

score 41 · Answer 4 · edited Aug 03 '20 at 21:03

41

Also be sure your home directory is not writeable by others:

chmod g-w,o-w /home/USERNAME

This answer is stolen from here.

edited Aug 03 '20 at 21:03

Peter Mortensen

30,738
21
105
131

answered Mar 06 '14 at 13:36

Stephan Hoyer

4,792
2
29
26

4

Doing `chmod 700 ~/.ssh ; chmod 600 ~/.ssh/authorized_keys ; chmod g-w,o-w ~` worked for me. Thanks. – gbraad Feb 14 '16 at 06:56
1

why not use just `chmod og-w /home/USERNAME` instead? – Paramvir Singh Karwal Nov 13 '18 at 13:16

score 16 · Answer 5 · edited Aug 03 '20 at 21:20

16

The desperate may also make sure they don't have extra newlines in the authorized_keys file due to copying file id_rsa.pub's text out of a confused terminal.

edited Aug 03 '20 at 21:20

Peter Mortensen

30,738
21
105
131

answered Oct 30 '14 at 03:39

Alexander Taylor

16,574
14
62
83

2

This is exactly what happened to me! the two terminals are same width so it's hard to figure out until I turned on the line numbers to see two lines in the authorized_keys file. – Shawn Apr 22 '15 at 20:39
1

This. I just wasted an hour because of this. And it's not the first time. @bortunac's answer mentions the ssh-copy-id tool, which I will use in the future to avoid this. – xdhmoore Jul 11 '17 at 20:00
I got the contents of `id_rsa.pub` using `more` instead of `cat`, which was fatal because of the invisible linebreaks. – Dan Halbert Jun 12 '20 at 02:51

score 8 · Answer 6 · edited Aug 03 '20 at 21:48

8

In the following, user is your username.

mkdir -p /home/user/.ssh
ssh-keygen -t rsa
touch /home/user/.ssh/authorized_keys
touch /home/user/.ssh/known_hosts
chown -R user:user /home/user/.ssh
chmod 700 /home/user/.ssh
chmod 600 /home/user/.ssh/id*
chmod 644 /home/user/.ssh/id*.pub
chmod 644 /home/user/.ssh/authorized_keys
chmod 644 /home/user/.ssh/known_hosts

edited Aug 03 '20 at 21:48

Peter Mortensen

30,738
21
105
131

answered Nov 14 '15 at 11:55

wcc526

3,915
2
31
29

Better for root: `mkdir -p /home/$USER/.ssh && chown -R $USER:$USER /home/$USER/.ssh && sudo -u $USER ssh-keygen -t rsa && touch /home/$USER/.ssh/authorized_keys && touch /home/$USER/.ssh/known_hosts && chmod 700 /home/$USER/.ssh && chmod 600 /home/$USER/.ssh/id* && chmod 644 /home/$USER/.ssh/id*.pub && chmod 644 /home/$USER/.ssh/authorized_keys && chmod 644 /home/$USER/.ssh/known_hosts && vim /home/$USER/.ssh/authorized_keys # paste keys here!` – Odysseus Jun 15 '16 at 14:59

score 8 · Answer 7 · edited Jun 07 '20 at 12:11

8

Listing a public key in .ssh/authorized_keys is necessary, but not sufficient for sshd (server) to accept it. If your private key is passphrase-protected, you'll need to give ssh (client) the passphrase every time. Or you can use ssh-agent, or a GNOME equivalent.

Your updated trace is consistent with a passphrase-protected private key. See ssh-agent, or use ssh-keygen -p.

edited Jun 07 '20 at 12:11

Peter Mortensen

30,738
21
105
131

answered Jun 16 '11 at 18:54

fche

2,641
20
28

score 7 · Answer 8 · edited Aug 03 '20 at 21:01

7

Beware that SELinux can trigger this error as well, even if all permissions seem to be OK. Disabling it did the trick for me (insert usual disclaimers about disabling it).

edited Aug 03 '20 at 21:01

Peter Mortensen

30,738
21
105
131

answered Oct 18 '13 at 09:39

Nim

631
6
12

You can see SELinux interfering in `/var/log/audit/audit.log`. `restorecon -R -v /root/.ssh` fixed my specific case. – Dave Goodell Feb 20 '17 at 22:21

score 6 · Answer 9 · edited Aug 03 '20 at 22:01

Look in file /var/log/auth.log on the server for sshd authentication errors.

If all else fails, then run the sshd server in debug mode:

sudo /usr/sbin/sshd -ddd -p 2200

Then connect from the client:

ssh user@host -p 2200

In my case, I found the error section at the end:

    debug1: userauth_pubkey: test whether pkalg/pkblob are acceptable for RSA SHA256:6bL+waAtghY5BOaY9i+pIX9wHJHvY4r/mOh2YaL9RvQ [preauth]
==> debug2: userauth_pubkey: disabled because of invalid user [preauth]
    debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth]
    debug3: userauth_finish: failure partial=0 next methods="publickey,password" [preauth]
    debug3: send packet: type 51 [preauth]
    debug3: receive packet: type 50 [preauth]

With this information I realized that my sshd_config file was restricting logins to members of the ssh group. The following command fixed this permission error:

sudo usermod -a -G ssh NEW_USER

This extra logging is very useful, thanks! It showed me that one of my keys -- copied and pasted into authorized_keys -- had a line break in the middle of it! — Quentin Stafford-Fraser, Apr 23 '21 at 22:08

score 5 · Answer 10 · answered Mar 05 '14 at 00:42

5

Try "ssh-add" which worked for me.

answered Mar 05 '14 at 00:42

h99

61
1
1

score 5 · Answer 11 · edited Aug 03 '20 at 21:21

5

The thing that did the trick for me finally was to make sure that the owner/group were not root, but user:

chown -R ~/.ssh/ user
chgrp -R ~/.ssh/ user

edited Aug 03 '20 at 21:21

Peter Mortensen

30,738
21
105
131

answered Nov 08 '14 at 09:37

Ulliroyal

51
1
1

1

chown: invalid user: ‘/home/lsa/.ssh/’ – Stepan Yakovenko Feb 16 '19 at 20:23
@Stepan Yakovenko: "user" is not literal(?). An improved answer could make this more clear. – Peter Mortensen Aug 03 '20 at 21:22

score 4 · Answer 12 · edited Aug 03 '20 at 21:04

4

Issue these on the command line:

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

After you do this, make sure your directory is like this:

drwx------ 2 lab lab 4.0K Mar 13 08:33 .
drwx------ 8 lab lab 4.0K Mar 13 08:07 ..
-rw------- 1 lab lab  436 Mar 13 08:33 authorized_keys
-rw------- 1 lab lab 1.7K Mar 13 07:35 id_rsa
-rw-r--r-- 1 lab lab  413 Mar 13 07:35 id_rsa.pub

edited Aug 03 '20 at 21:04

Peter Mortensen

30,738
21
105
131

answered Mar 13 '14 at 08:42

Exsonic

479
6
3

2

how your answer is different with accepted one? You've wrote it 3 years later using your Ctrl+C Ctrl-V command? – stinger Feb 08 '19 at 11:47

score 3 · Answer 13 · edited Aug 03 '20 at 21:54

3

Another tip to remember: Since v7.0 OpenSSH disables DSS/DSA SSH keys by default due to their inherit weakness. So if you have OpenSSH v7.0+, make sure your key is not ssh-dss.

If you are stuck with DSA keys, you can re-enable support locally by updating your sshd_config and ~/.ssh/config files with lines like so: PubkeyAcceptedKeyTypes=+ssh-dss

edited Aug 03 '20 at 21:54

Peter Mortensen

30,738
21
105
131

answered Apr 29 '16 at 12:04

user2683246

3,399
29
31

score 3 · Answer 14 · edited Aug 03 '20 at 21:57

3

Another issue you have to take care of: If your generated file names are not the default id_rsa and id_rsa.pub.

You have to create the .ssh/config file and define manually which id file you are going to use with the connection.

An example is here:

Host remote_host_name
    HostName 172.xx.xx.xx
    User my_user
    IdentityFile /home/my_user/.ssh/my_user_custom

edited Aug 03 '20 at 21:57

Peter Mortensen

30,738
21
105
131

answered Feb 02 '17 at 09:41

Kunthar

472
1
5
15

2

The IdentityFile should be the private key – Ken H Aug 14 '18 at 15:59
@KenH yeah sure. typo it is. sorry for that. – Kunthar Nov 24 '18 at 22:32

score 3 · Answer 15 · answered Feb 22 '17 at 18:00

3

In my case I needed to put my authorized_keys file in .openssh.

This location is specified in /etc/ssh/sshd_config under the option AuthorizedKeysFile %h/.ssh/authorized_keys.

answered Feb 22 '17 at 18:00

Sean Bannister

3,105
4
31
43

1

There's a whole class of problems that can occur on the server (when trying to connect from a client) that are impossible to debug without access to the server... This is by design to hide info from malicious clients, but makes it harder to debug. – qneill Dec 15 '17 at 17:53

score 2 · Answer 16 · answered Nov 15 '14 at 06:17

2

Make sure that the target user has a password set. Run passwd username to set one. This was required for me even if password SSH login was disabled.

answered Nov 15 '14 at 06:17

George

303
2
7

score 2 · Answer 17 · edited Aug 03 '20 at 21:58

2

Just look in file /var/log/auth.log on the server. Setting additional verbosity with -vv on the client side won't help, because the server is unlikely to offer too much information to a possible attacker.

edited Aug 03 '20 at 21:58

Peter Mortensen

30,738
21
105
131

answered Jan 19 '18 at 16:19

Edward van Kuik

1,357
1
9
9

score 1 · Answer 18 · edited Aug 03 '20 at 21:34

1

I issued sudo chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys and chmod go-w $HOME $HOME/.ssh from a previous answer and it fixed my problem on a CentOS 7 box that I had messed up the permissions on while trying to get Samba shares working.

edited Aug 03 '20 at 21:34

Peter Mortensen

30,738
21
105
131

answered May 01 '15 at 00:53

GJSmith3rd

806
5
7

score 1 · Answer 19 · edited Aug 03 '20 at 21:48

1

It seems like a permission problem. Usually it happens if the permission of some file/directory is not correctly set up. In most case they are ~/.ssh and ~/.ssh/*. In my case they are /home/xxx.

You can change the log level of sshd by modifying file /etc/ssh/sshd_config(search for LogLevel, and set it to DEBUG) and then check the output in file /var/log/auth.log to see what happened exactly.

edited Aug 03 '20 at 21:48

Peter Mortensen

30,738
21
105
131

answered May 08 '15 at 01:09

Joey

21
2

3

This looks substantially identical to the accepted answer and should probably have been a comment on it, not an answer. With a bit more rep, [you will be able to post comments](http://stackoverflow.com/privileges/comment). Until then, please do not use answers as a workaround. – Nathan Tuggy May 08 '15 at 01:31
Sorry, I thought it's the way to solve all kinds of this question. Now I know how to do it now, thanks. – Joey May 11 '15 at 01:14

score 1 · Answer 20 · edited Aug 03 '20 at 21:48

1

This solves my problem:

ssh-agent bash

ssh-add

edited Aug 03 '20 at 21:48

Peter Mortensen

30,738
21
105
131

answered Jun 21 '15 at 14:57

Julian

334
4
18

2

Explain what that does, please. – Lyuboslav Apr 13 '18 at 10:18
The ssh-agent stores your ssh keys..the command bash starts a new instance of its shell. and ssh-add unlocks your keys and loads them – Julian Apr 13 '18 at 16:45

score 1 · Answer 21 · edited Aug 03 '20 at 21:51

1

In my case it's because the user's group is not set in AllowGroups of configuration file /etc/ssh/sshd_config. After adding it, everything works fine.

edited Aug 03 '20 at 21:51

Peter Mortensen

30,738
21
105
131

answered Jan 26 '16 at 06:39

pppk520

517
4
15

score 1 · Answer 22 · answered Mar 28 '16 at 19:07

My problem was a modified AuthorizedKeysFile, when the automation to populate /etc/ssh/authorized_keys had not yet been run.

$sudo grep AuthorizedKeysFile /etc/ssh/sshd_config
#AuthorizedKeysFile .ssh/authorized_keys
AuthorizedKeysFile  /etc/ssh/authorized_keys/%u

Willem · Answer 23 · 2018-02-22T11:36:26.480

1

Make sure you've copied the whole public key to authorized_keys; the ssh rsa prefix is necessary for the key to work.

edited Feb 22 '18 at 11:36

answered Jan 09 '18 at 08:15

Willem

317
2
11

2

used ssh-copy-id – Vishnu Pradeep Jun 28 '18 at 08:48

score 1 · Answer 24 · edited Aug 03 '20 at 21:58

1

You need to verify the properties of the files.

To assign the required property, use:

$ chmod 600 ~/.ssh/sshKey
$ chmod 644 ~/.ssh/sshKey.pub

edited Aug 03 '20 at 21:58

Peter Mortensen

30,738
21
105
131

answered May 03 '18 at 23:29

Manna

27
4

score 0 · Answer 25 · edited Aug 03 '20 at 21:26

0

On that note, make sure your sshd configuration has this line:

PermitRootLogin without-password

Set as the above, and then restart sshd (/etc/init.d/sshd restart).

Log out and try log in in again!

The default, I believe, is:

PermitRootLogin no

edited Aug 03 '20 at 21:26

Peter Mortensen

30,738
21
105
131

answered Feb 03 '15 at 09:59

Edd Stance

1

score 0 · Answer 26 · edited Aug 03 '20 at 21:56

I have the home directory in a non-standard location and in sshd logs I have the following line, even if all permissions were just fine (see the other answers):

Could not open authorized keys '/data/home/user1/.ssh/authorized_keys': Permission denied

I have found a solution here: Trouble with ssh public key authentication to RHEL 6.5

In my particular case:

Added a new line in /etc/selinux/targeted/contexts/files/file_contexts.homedirs:
This is the original line for regular home directories:

/home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0
This is my new line:

/data/home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0
Followed by a restorecon -r /data/ and a sshd restart.

score 0 · Answer 27 · edited Aug 03 '20 at 22:00

I had this problem and none of the other answers solved it, although of course the other answers were correct.

In my case, it turned out that the /root directory itself (not e.g. /root/.ssh) had the wrong permissions. I needed:

chown root.root /root
chmod 700 /root

Of course, those permissions should be something like that (maybe chmod 770) regardless. However, it specifically prevented sshd from working, even though /root/.ssh and /root/.ssh/authorized_keys both had correct permissions and owners.

score 0 · Answer 28 · edited Aug 03 '20 at 22:03

I had this problem when I added the group of the login user to another user.

Let's say there is an SSH-login user called userA and a non-SSH-login user userB. userA has the group userA as well. I modified userB to have the group userA as well. The lead to the the described behaviour, so that userA was not able to login without a prompt.

After I removed the group userA from userB, the login without a prompt worked again.

score 0 · Answer 29 · answered Jun 22 '20 at 08:36

0

I use it this way.

cat ~/.ssh/id_rsa.pub| ssh user@remote-system 'umask 077; cat >>~/.ssh/authorized_keys'

answered Jun 22 '20 at 08:36

Zafer BAHADIR

99
4

An explanation would be in order. – Peter Mortensen Aug 03 '20 at 22:04

score 0 · Answer 30 · edited Aug 03 '20 at 22:09

I have had the same issues since before, but today I had to set up one new server. What I could learn in this time...

The basic process to allow authentication without a password is as follows:

On the server, validate if your home folder has the .ssh folder. If it doesn't exist, you can create it manually with a mkdir command and then to assign the correct permissions with chmod, or otherwise you could use the same utility, ssh-keygen, to create private/public keys, but on the server for your user. This process will create the required .ssh folder.
On the local machine you also need to create the private/public keys with the ssh-keygen utility.
You need to move your public key to file .ssh/authorized_keys to the server. To achieve this, you can use the ssh-copy-id utility, or you can do it manually using the cat and scp commands.
In the best of cases, this will allow connect to your server without a password.

OK, now the issues that I found today: first there are several key generation algorithms: rsa, dsa, ecdsa and ed25519 and there are many releases of OpenSSH (you can have one version on your local machine and an old version on your server):

Hint: Using ssh -v helps to see additional information when you are connecting to the server.

OpenSSH_8.2p1 Ubuntu-4, OpenSSL 1.1.1f 31 Mar 2020

debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3

The error in my case today was that I was trying to use a key with a "newer" generation algorithm that was not supported by the installed version of OpenSSH on the server. When I had checked the supported algorithms, another error that I found was that the server was rejecting my algorithm:

debug1: Skipping ssh-dss key /home/user/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes

After that, I had to change the algorithm of my key and then I could connect with the server successfully.

OpenSSH releases notes: Link

score 0 · Answer 31 · answered Aug 25 '22 at 08:19

In this case, we'll move the root key to the example_user, which also disables the root user's SSH key access.

SSH to the instance as root.

Create the .ssh directory for example_user.

# mkdir /home/example_user/.ssh

Move the root key to example_user's SSH directory.

# mv /root/.ssh/authorized_keys /home/example_user/.ssh/

Change the ownership of the .ssh directory from root to example_user so OpenSSH can read it.

# chown -R example_user:example_user /home/example_user/.ssh

Source - https://www.vultr.com/docs/using-your-ssh-key-to-login-to-non-root-users#Option_2__Move_the_root_SSH_Key_to_the_Non_root_User

score 0 · Answer 32 · answered Feb 25 '23 at 11:21

After setting the correct permissions, ssh still wouldn't log me in without the password.

So, after combing through the /var/log/auth.log I saw

Authentication refused: bad ownership or modes for directory /root

In addition to setting permissions, ownership needed to be set. On server side, do

chown root /root
chown root /root/.ssh

and then

chmod go-w ~/ 
chmod 700 ~/.ssh 
chmod 600 ~/.ssh/authorized_keys

Credit: here.

Adding a public key to ~/.ssh/authorized_keys does not log me in automatically

32 Answers32

Linked