ssh returns "Bad owner or permissions on ~/.ssh/config"

Question

When I try to ssh to another box, I get this strange error

$ ssh hostname
Bad owner or permissions on ~/.ssh/config

But I made sure that I own and have rw permissions on the file:

ls -la ~/.ssh/
total 40K
drwx------ 2 robert robert 4.0K Mar 29 11:04 ./
drwx------ 7 robert robert 4.0K Mar 29 11:04 ../
-rw-r--r-- 1 robert robert 2.0K Mar 17 20:47 authorized_keys
-rw-rw-r-- 1 robert robert   31 Mar 29 11:04 config
-rw------- 1 robert robert 1.7K Aug  4  2010 id_rsa
-rw-r--r-- 1 robert robert  406 Aug  4  2010 id_rsa.pub
-rw-r--r-- 1 robert robert 6.1K Mar 29 11:03 known_hosts

I just had the same message. My case was different. I was having a global `IdentityFile ~/.ssh/id_rsa` set, so when I was trying to access user@myserver.com it was trying to use that id_rsa without questioning me the password. Avoid the global IdentityFile and it will all go well. — giovannipds, Oct 03 '19 at 19:12
This happened to me on macOS after installing SourceTree - I opened up the `config` file and found there was nothing useful in it, just generated code by SourceTree, which I no longer use anyway. Removing the file (renaming it to config.bak) solved my issue! — Janac Meena, Apr 18 '22 at 14:04

Robert · Accepted Answer · 2021-11-11T04:52:09.173

857

I needed to have rw for user only permissions on config. This fixed it.

chmod 600 ~/.ssh/config

As others have noted below, it could be the file owner. (upvote them!)

chown $USER ~/.ssh/config

If your whole folder has invalid permissions here's a table of possible permissions:

Path	Permission
.ssh directory (code)	0700 (drwx------)
private keys (ex: `id_rsa`) (code)	0600 (-rw-------)
`config`	0600 (-rw-------)
public keys (*.pub ex: `id_rsa.pub`)	0644 (-rw-r--r--)
`authorized_keys` (code)	0644 (-rw-r--r--)
`known_hosts`	0644 (-rw-r--r--)

Sources:

openssh check-perm.c
openssh readconf.c
openssh ssh_user_config fix_authorized_keys_perms

edited Nov 11 '21 at 04:52

answered Mar 29 '11 at 18:16

Robert

14,423
4
18
14

30

Sometimes it's not only the permissions, but also the owner that can cause the problem; in my case, I had to do this as well: `chown -R robert:robert ~/.ssh` – Nicolas C Jan 26 '15 at 12:27
9

In my case, going from 644 to 600 did the trick. – user3653831 Oct 18 '16 at 18:15
5

Just read permission should be sufficient, i.e. `400` – 030 Jan 02 '17 at 00:06
3

For me, `600` didn't work, only `400` (on Ubuntu Xenial) – Martín Coll Oct 25 '17 at 00:35
@030 As long as you don't intend to edit the file.. – Sean the Bean Nov 16 '17 at 13:31
1

You have to be the only one who can read or write that file, otherwise other people can compromise your security. Any other owner or r/w permission makes the file untrustworthy and therefore it is not used. – simpleuser May 01 '18 at 22:02
My file was empty. Setting any permissions did not help, so I deleted it. Then it worked. – Markus Zeller Mar 08 '19 at 13:40
2

To my surprise, 660 is considered "Bad owner or permissions on ~/.ssh/config" but 600 isn't. Thanks! – HCSF Jul 04 '19 at 03:47
Fresh Fedora (i am loving the ws30) install. This was causing trouble and 0600 mod fixed it. Thanks @Robert – Vijay Kumar Kanta Oct 05 '19 at 09:46
chmod 600 ~/.ssh/config - it worked for me, thanks! – Adil May 06 '20 at 09:17
1

@HCSF "Because of the potential for abuse, this file [.ssh/config] must have strict permissions: read/write for the user, and not writable by others", cf. https://man.openbsd.org/ssh_config.5#FILES . The other approaches did not work for me. Indeed, I can recommend to run `chmod 0700 ~/.ssh` and then `chmod 0600 ~/.ssh/*` to correctly set the permissions for the whole .ssh directory. – el_tenedor Apr 12 '21 at 18:03
2

"You have to be the only one who can read or write that file" as @simpleuser said (and most others ment) is accurate. Wording matters because there is another way to mess this up: If you add another account to your group (see /etc/groups) you will not be the only user any more. That quirk doesn't show in neither permissions nor owner of `~/.ssh/*` – Michael Ambrus Aug 18 '21 at 20:26
2

I'm just wondering. What kind of things cause these permissions to become reversed? I came back to my terminal and was surprised that I couldn't access my Git repo anymore because of this (and the solution fixed the issue). What the heck? – mig81 Dec 09 '21 at 00:34

kenorb · Answer 2 · 2015-08-03T11:35:27.107

108

These commands should fix the permission problem:

chown $USER ~/.ssh/config
chmod 644 ~/.ssh/config

Prefix with sudo if the files are owned by different user (or you don't have access to them).

If more files are affected, replace config with *.

In man ssh we can read:

Because of the potential for abuse, this file must have strict permissions: read/write for the user, and not writable by others. It may be group-writable provided that the group in question contains only the user.

edited Aug 03 '15 at 11:35

answered Aug 03 '15 at 11:30

kenorb

5,943
1
44
53

4

This did the trick for me. I am using cygwin and cygwin .ssh is symlinked to windows user .ssh. I had to run those commands in cygwin window. – Damodar Bashyal Apr 27 '16 at 05:54
This worked for me. – Viraj Wadate May 25 '19 at 07:17
This worked for me. `chown` was not necessary, since the file was already owned from the right account. I was not understanding how the permissions could be wrong, until I read this answer. – apaderno May 29 '20 at 18:46
Yep, I find myself coming back to this answer every now and then :-) – ArchNoob Dec 02 '20 at 10:04

score 18 · Answer 3 · answered May 28 '15 at 01:07

18

For me it was an issue with my user account not being the owner of the file

sudo chown myuser ~/.ssh/config

answered May 28 '15 at 01:07

svnm

281
2
4

Nathan Kidd · Answer 4 · 2020-01-13T17:14:20.010

14

If on Windows Subsystem for Linux (WSL) and you pointed your WSL home directory to your Windows home directory (not recommended!) then chmod has no effect. Before you can chmod the files mentioned in other answers you must add

[automount]
options = "metadata"

to your /etc/wsl.conf then restart WSL (requires build 17093 or later).

Before mount says:

C: on /mnt/c type drvfs (rw,noatime,uid=1000,gid=1000,case=off)

After mount says:

C: on /mnt/c type drvfs (rw,noatime,uid=1000,gid=1000,metadata,case=off)

edited Jan 13 '20 at 17:14

answered Aug 22 '19 at 19:26

Nathan Kidd

255
2
5

3

I'm on Windows 10 Version 1903 and chmod in WSL just worked. – ahofmann Oct 23 '19 at 15:05

score 3 · Answer 5 · answered Jan 13 '20 at 21:10

3

Don't forget about the group:

chown $USER:$USER ~/.ssh/config

:-)

answered Jan 13 '20 at 21:10

Alexander Gavriliuk

171
4

The group does not matter if the file is not group writable. If it is, the group must at most contain the user. – Piotr P. Karwasz Jan 13 '20 at 23:23
I just thought that if this file unexpectedly has a wrong user, it also can have a wrong group. To make all things right we'd better take an attention on the group too. – Alexander Gavriliuk Jan 14 '20 at 13:24

score 1 · Answer 6 · answered Feb 27 '20 at 04:02

I met this issue on windows 10 with vagrant ssh. And tried all the above methods, but get no luck. Finally I deleted that ssh config file and then it works!

vagrant ssh
Bad owner or permissions on C:\\Users\\Jeff/.ssh/config
del ..\.ssh\config

vagrant ssh
Welcome to Ubuntu 14.04.6 LTS (GNU/Linux 3.13.0-170-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

  System information as of Thu Feb 27 02:23:03 UTC 2020

  System load:  0.0               Processes:              77
  Usage of /:   5.1% of 39.34GB   Users logged in:        0
  Memory usage: 21%               IP address for eth0:    10.0.2.15
  Swap usage:   0%                IP address for docker0: 172.17.0.1

  Graph this data and manage this system at:
    https://landscape.canonical.com/

New release '16.04.6 LTS' available.
Run 'do-release-upgrade' to upgrade to it.


vagrant@vagrant-ubuntu-trusty-64:~$

This doesn't help if I need the contents of the config file to be used when logging into a remote ssh host — shonky linux user, Sep 01 '20 at 01:18
this worked for me same issues vagrant ssh was not working created a backup of the config file and then tried vagrant ssh and it worked. Thanks — Rohit Salecha, Jan 11 '21 at 12:23

ssh returns "Bad owner or permissions on ~/.ssh/config"

6 Answers6

Linked