52

I have realized that I am no longer able to connect to the webserver at x.x.202.50. Yesterday I have changed the following ssh configuration file: /share/homes/admin/.ssh/config by adding the following settings:

# ssh (secure shell) configuration file
Host webserver
    HostName x.x.212.50
    User user1
    IdentityFile ~/.ssh/id_rsa `

The reason I did this is to enable key login for synchronization purpose (with Unison).

Now, when I try to connect to the server I receive the following error:

Bad owner or permissions on /share/homes/admin/.ssh/config

I make the connection with Putty from Windows 10 and from Linux server to another Linux server.

I need to connect to the server because I am involved in a project, and I don't know how to do it. Does anybody know how to do this?

Jakuje
  • 10,032
  • 5
  • 33
  • 34
symp Ioio
  • 621
  • 1
  • 5
  • 4
  • 9
    `chmod 600 /share/homes/admin/.ssh/config` should fix it. This gives the owner rw permissions and nobody else. – Magnus May 24 '17 at 12:16
  • Could you run `ls -ld /share/homes/admin/.ssh /share/homes/admin/.ssh/config` and [edit] your question to include the output? – Kenster May 24 '17 at 13:02

5 Answers5

86

You need to change the permissions of .ssh directory. Run the following, (I found 600 will not fix it on its own):

chmod 700 ~/.ssh
chmod 600 ~/.ssh/*
Aindriú
  • 966
  • 1
  • 8
  • 14
  • 1
    It helped me a lot, thanks! I just changed my computer and did a copy of the `ssh` folder, but didn't work good. The problem was the access right. Great! – Everton Costa Aug 08 '22 at 14:51
  • You can simply use `chmod -R` to recursively modify permissions of all files in a folder. – mashuptwice Nov 28 '22 at 16:02
  • This solution is wrong because it will also make the public keys unreadable by others. – Yaron Cohen-Tal Mar 06 '23 at 10:28
  • This solution is just fine: there's typically no downside to keeping your public key files unreadable by others. If it's needed somewhere else you can transmit it freely. – Allen Luce Mar 18 '23 at 01:32
25

The general rule for the files that can affect the security (private keys, configuration files, authorized keys) is that they should not be writable by anyone else than the owner (the private keys should not be accessible!).

The error is coming from the openssh code below:

if (((sb.st_uid != 0 && sb.st_uid != getuid()) ||
    (sb.st_mode & 022) != 0))
      fatal("Bad owner or permissions on %s", filename);

So translating it to the English, means that the config file must be owned by root or by the user running the ssh and can not be writable by any group or other users.

As already pointed out in the comments, you probably gave this permissions to somebody somehow so removing these permissions should fix that problem:

chmod go-w /share/homes/admin/.ssh/config
Jakuje
  • 10,032
  • 5
  • 33
  • 34
1

If your home directory is mounted on NFS and there is an NFS problem or a Domain login problem, it could be that the ~/.ssh/config file is owned by nobody (temporarily, until the NFS or Domain loging problem is fixed). This doesn't fix your problem, but the problem may not be with the permissions. Just do ls -la on the directory and make sure the files are still yours. And if you see nobody, time to send an email to IT.

mashuptwice
  • 2,929
  • 2
  • 12
  • 25
Mark Lakata
  • 8,340
  • 2
  • 18
  • 16
1

I have a single user Linux machine that shares the same '.ssh' directory with the root account. The /root/.ssh is a symbolic link that points to the user's '/home/username/.ssh' folder.

I only recently added a ~/.ssh/config file and this caused SSH to give me the error message when invoking SSH and SSHFS from the root account. The solution for me was to do the following:

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

This is a bit of a problem when I have to edit the file though, since it requires me to mess with the permissions and ownership of the file, then flip them back. But that is my own problem because I choose to share the folder between the accounts. I created some shell scripts to flip the permissions around only when invoking the 'sshfs' or 'ssh' command from using the root user account.

C.D.
  • 131
  • 5
0

The other answers only solve the problem if there is a wrong permission. However, in my case the problem was a wrong file owner. You can run ls -l ~/.ssh to view the information about permissions and owners. File owner can be seen in the 3rd column. If it is wrong, execute:

chown <newOwner> <fileName>
Miloš Černilovský
  • 101
  • 2