30

I have a very specific requirement that requires a private key to be used by multiple users. I know how bad this is. The problem is that if the identity file's permission is to permissive (444 in my case) ssh will simply ignore them.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @        
WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0444 for '/var/vendor/id_rsa' are too open. It is
recommended that your private key files are NOT accessible by others.
This private key will be ignored.

From the man pages

Contains the private key for authentication. These files contain sensitive data and should be readable by the user but not accessible by others (read/write/execute). ssh will simply ignore a private key file if it is accessible by others.

Is there a way to force ssh to use the key without checking the permissions?

Improve this question

6 Answers 6

Reset to default
24

As other answers have mentioned, it looks like there is no way to force SSH to ignore that option. The check is happening in authfile.c function sshkey_perm_ok:

if ((st.st_uid == getuid()) && (st.st_mode & 077) != 0) {
    error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
    error("@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @");
    error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
    error("Permissions 0%3.3o for '%s' are too open.",
        (u_int)st.st_mode & 0777, filename);
    error("It is required that your private key files are NOT accessible by others.");
    error("This private key will be ignored.");
    return SSH_ERR_KEY_BAD_PERMISSIONS;
}

If changing the permissions of the key file is not an option, a solution is to download the OpenSSH source, remove that check from the code and rebuild it.

Improve this answer
2
  • 6
    This permission check is severely outdated (I mean, who in their right mind keeps unprotected private keys in the open nowadays instead of encrypted containers and such?) and should be banished from the source code. I wonder why there is no fork of OpenSSH without this silly check. Good thing that on Windows you can just put all the keys inside encrypted container formatted into FAT32 file system and forget about permission juggling.
    – izogfif
    Dec 27, 2021 at 21:29
  • I had to remove the same check from read_config_file_depth in readconf.c
    – Gordy
    Dec 31, 2022 at 23:01
5

An answer to a related question suggests there is no way to bypass the permissions check.

However, I had the same problem --- I wanted several users to share the same key to be able to access and control a large group of hosts --- and my fix might be useful to others.

Here's what I did:

  1. Create a special user (say, master) and group (master) to hold the key.
  2. Create/store the key files in ~master/.ssh/.
  3. Give group read permissions to the key file, chmod g+r ~master/.ssh/id_rsa.
  4. Add each of the authorized users to the master group.
  5. Make a link from ~user/.ssh/id_rsa to ~master/.ssh/id_rsa.

This allows the authorized user to ssh without problems, but avoids opening up the key to everyone. Also, the key owner is not root.

Strangely, the master user itself will still get the "unprotected private key" warning. This can be circumvented by changing the owner (but not the group) of the key file to some special user that will never need to use the key, sudo chown daemon ~master/.ssh/id_rsa, for instance.

Improve this answer
4
  • 1
    The fact that the permission check is only performed when ssh is run by the key file's owner was a surprise when I tried sharing a key. In my isolated environment changing the owner of the file to root was an acceptable approach. Thanks for pointing this out!
    – Tore Olsen
    Nov 4, 2020 at 13:07
  • There's no need to change the location of the key at all, just keep it where it is and chown it to nobody. All the permission bits for the group and others can stay just like they are, changing the owner is enough to disable the check in SSH.
    – TooTea
    May 25, 2021 at 11:27
  • @TooTea, Do you mean changing the owner of id_rsa to nobody AND setting the permissions to the permissive 0444 will do it? Of course this will still be exposing the file to everybody, which may not be what was intended.
    – João Rodrigues
    May 25, 2021 at 14:00
  • 1
    Yes, exactly. You can see in the answer by Andrei Savin that the check only triggers if st.st_uid == getuid(). Thus as long as the user running ssh doesn't match the owner of the file, the check is ignored. Whether or not it's wise to make the key world readable is IMHO not the topic of this question. I assume that OP read the warning and came to the conclusion that they indeed want to just override the warning.
    – TooTea
    May 25, 2021 at 14:03
4

You could make it available for raeding with Access Control Lists. Use the utilities getfacl and setfacl.

Remember to also set a proper mask with setfacl, because normally any separate permissions you will add won't be effective if the group permissions aren't the same.

Your file system needs to support it, though. If it's not enabled, you have to add the mount option in your fstab.

Improve this answer
3
  • setfacl modified the permissions and ssh complained again. Weird thing is when I use the id_rsa from a user other than root who has access to the key everything is fine, but when I try to ssh from the root ssh complains.
    – mshohayeb
    Mar 16, 2014 at 10:01
  • Sadly this doesnt work either. If you use ACL, the part of the permissions (displayed by ls or so) then represent the (ACL) mask. Which is usally rw- (and cannot be --- because this would deny all access at all, since mask represents the max. permissions) So this will not fulfill the condition from above. Sadly SSH just seems to check the classical permissions and not via ACL.
    – milkpirate
    Feb 21, 2023 at 23:06
  • Works like a charm. On FreeBSD with ZFS the key file has standard 600 permissions, but I am allowing group devops to read it as well: setfacl -m g:devops:r:allow /var/vendor/id_rsa
    – Marián Černý
    Jan 11 at 19:37
3

As everyone suggests there is no way to bypass the security checks.

But you can create a copy of the key and change the permissions on this key:

# Copy your key to a new location
cp <<your_key>> <<new_key>>

# Make sure you are the owner
chown <<your_user>>:<<your_user>> <<new_key>>

# Give yourself the full permissions while removing all access for others
chmod 700 <<new_key>>

It worked for me.

Improve this answer
2
  • -1 As you can see in the other answers, there are two different ways to bypass the security checks (either chown nobody id_rsa, or chmod 0600 id_rsa plus setfacl to add the necessary permissions for others). The rest of your answer doesn't answer the question as asked.
    – TooTea
    May 25, 2021 at 11:25
  • I like this answer because it's simple and straightforward, and doesn't bother with tricky features like symlinks and the nobody account. And, contrary to what @TooTea asserts above, it does answer the question as asked ("Is there a way to force ssh to use the key without checking the permissions?" -> "there is no way to bypass the security checks.").
    – Eric Dand
    Apr 2 at 22:29
1

The comment from @João Rodrigues to the answer from @Andrei Savin gives at the end a hint for me using sudo:

sudo -u nobody ssh -i <path to identity file> <ssh server>

The following error messages (examples)

Could not create directory '/var/empty/.ssh'.
The authenticity of host 'xxx' can't be established.
ECDSA key fingerprint is SHA256:yyy.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Failed to add the host to the list of known hosts (/var/empty/.ssh/known_hosts).

could be ignored. It works out-of-the-box using Debian Buster (OpenSSH_7.9p1, OpenSSL 1.1.1d) and MacOS Big Sur (OpenSSH_8.1p1, LibreSSL 2.7.3).

Improve this answer
0

A suggestion from a different perspective:

SSH works with a file (usually ~/.ssh/authorized_keys, if you have access to the file system of the server) to decide what key pairs to allow to be used for an account.

If you can edit this file, just append the public key from each user to this file for the account in question, and they all will be allowed to log on to this account. If someone quits or changes job description, remove their pubkey from the file.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .