Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers. Visit Stack Exchange

Server Fault is a question and answer site for system and network administrators. It only takes a minute to sign up.

Sign up to join this community

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

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? 
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.
                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
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:
Create a special user (say, master) and group (master) to hold the key.
Create/store the key files in ~master/.ssh/.
Give group read permissions to the key file, chmod g+r ~master/.ssh/id_rsa.
Add each of the authorized users to the master group.
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.
                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
                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
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.
                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 at 23:06
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.
                -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
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).
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.