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

Solution 1

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

Solution 2

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.

Solution 3

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

sudo chown myuser ~/.ssh/config

Solution 4

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)

Solution 5

Don't forget about the group:

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

:-)

View more solutions

Comments

[Admin]

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 [email protected] it was trying to use that id_rsa without questioning me the password. Avoid the global IdentityFile and it will all go well.

[Admin]

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!

[Nicolas C]

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

[Damodar Bashyal]

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.

[user3653831]

In my case, going from 644 to 600 did the trick.

[030]

Just read permission should be sufficient, i.e. 400

[Martín Coll]

For me, 600 didn't work, only 400 (on Ubuntu Xenial)

[Sean the Bean]

@030 As long as you don't intend to edit the file..

[simpleuser]

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.

[Markus Zeller]

My file was empty. Setting any permissions did not help, so I deleted it. Then it worked.

[Viraj Wadate]

This worked for me.

[HCSF]

To my surprise, 660 is considered "Bad owner or permissions on ~/.ssh/config" but 600 isn't. Thanks!

[Vijay Kumar Kanta]

Fresh Fedora (i am loving the ws30) install. This was causing trouble and 0600 mod fixed it. Thanks @Robert

[ahofmann]

I'm on Windows 10 Version 1903 and chmod in WSL just worked.

[Piotr P. Karwasz]

The group does not matter if the file is not group writable. If it is, the group must at most contain the user.

[Alexander Gavriliuk]

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.

[Adil]

chmod 600 ~/.ssh/config - it worked for me, thanks!

[apaderno]

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.

[shonky linux user]

This doesn't help if I need the contents of the config file to be used when logging into a remote ssh host

[ArchNoob]

Yep, I find myself coming back to this answer every now and then :-)

[Rohit Salecha]

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

[el_tenedor]

@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. 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.

[Michael Ambrus]

"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/*

[mig81]

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?