11

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?

13

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.

2

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.

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 '20 at 13:07
1

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.

1
  • 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 '14 at 10:01
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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.