Bad owner or permissions on /root/.ssh/config means the SSH client refused to read your ~/.ssh/config, and stopped, because the file was writable by others (modes 666 and 646 in this test) or owned by another user (nobody); a group-writable 664 file was accepted. Make it yours and give it mode 600: chmod 600 ~/.ssh/config, plus chown if the owner is wrong.

In this test the client printed this one line and exited with code 255, with no login output at all; the fix took effect on the next command.

The error

$ chmod 666 /root/.ssh/config; ls -l /root/.ssh/config
-rw-rw-rw- 1 root root 23 Nov 13 05:37 /root/.ssh/config
exit=0
$ ssh -o BatchMode=yes sshd hostname
Bad owner or permissions on /root/.ssh/config
exit=255

Why it happens

The config file held two lines (Host sshd and User dev). With mode 666 every user on the machine could change it, and the client refused it. Which modes triggered the message in this test:

  • 666 (writable by everyone): refused.
  • 646 (writable by others, not by the group): refused.
  • 664 (writable by the group root, root's own group): accepted, the login worked.
  • 600 owned by another user (nobody): refused.
  • 600 owned by root: accepted.

The owner case looked like this:

$ chown nobody /root/.ssh/config; ls -l /root/.ssh/config
-rw------- 1 nobody root 23 Nov 13 05:37 /root/.ssh/config
exit=0
$ ssh -o BatchMode=yes sshd hostname
Bad owner or permissions on /root/.ssh/config
exit=255

Each refused run printed the same single line, whatever the cause, so ls -l on the file is what shows whether the mode or the owner is wrong. The group-writable 664 file passing is what this OpenSSH build did with a file whose group is the owner's own group; other group set-ups were not tested, so 600 is the safe target.

The fix

$ chmod 600 /root/.ssh/config; ls -l /root/.ssh/config
-rw------- 1 root root 23 Nov 13 05:37 /root/.ssh/config
exit=0
$ ssh -o BatchMode=yes sshd hostname
9aec0d80cdf9
exit=0

After chmod 600 the client read the config, used User dev from it, and logged in. For the wrong-owner case, chown root /root/.ssh/config (the user who runs ssh) fixed it the same way, as the evidence shows.

How it was reproduced

Reproduced inside ubuntu:24.04 containers on one user-defined Docker network on Docker engine 29.9.3, with OpenSSH_9.6p1 Ubuntu-3ubuntu13.20 as client and server. The client ran as root with a config file written by printf; the server had a test user dev holding the client's public key. The containers and the network were removed afterwards.

Frequently asked

How do I fix Bad owner or permissions on ~/.ssh/config?
Make the file owned by the user who runs ssh and set it to mode 600 with chmod 600 ~/.ssh/config. In this test the next ssh command worked.
What permissions should ~/.ssh/config have?
600 worked in every test here. 666 and 646 were refused, and 664 with the owner's own group was accepted.
Can a wrong owner cause Bad owner or permissions?
Yes. In this test a mode 600 config owned by the user nobody was refused for root, and chown back to root fixed it.

The private key file has its own mode check, with a different message: SSH: Permissions 0644 are too open. More decoded errors in the Fixes category.