Sometimes in development environments or CI/CD pipelines, we encounter situations where multiple system users need to share an SSH private key. While this violates security best practices, certain legacy systems or vendor requirements may force this architecture.

# Typical error when permissions are too open
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
WARNING: UNPROTECTED PRIVATE KEY FILE!
Permissions 0444 for '/shared_keys/deploy_key' are too open.
This private key will be ignored.

OpenSSH enforces strict permission checks (0600 for private keys) to prevent accidental exposure. The check happens in the sshkey_load_private() function within OpenSSH's source code. When it detects group/other permissions, it fails hard for security reasons.

For controlled environments where security trade-offs are acceptable:

Option 1: SSH Config Directive

Add this to /etc/ssh/ssh_config or ~/.ssh/config:

StrictHostKeyChecking no
UserKnownHostsFile /dev/null
LogLevel QUIET

Note: This only bypasses host key checks, not permission checks.

Option 2: Use SSH-Agent Forwarding

Have one user load the key into ssh-agent:

chmod 600 id_rsa
ssh-add id_rsa

Then other users can access via:

ssh -A user@host

Option 3: Recompile OpenSSH with Modified Checks

For extreme cases, modify sshkey.c in OpenSSH source:

// Comment out or modify the permission check
// if (!platform_sys_dir_uid(uid) && ((st.st_mode & 077) != 0))

Then rebuild and install. Warning: This voids security guarantees.

Option 4: Use a Wrapper Script

Create a temporary copy with correct permissions:

#!/bin/bash
TEMP_KEY=$(mktemp)
cp /shared_keys/deploy_key $TEMP_KEY
chmod 600 $TEMP_KEY
ssh -i $TEMP_KEY $@
rm $TEMP_KEY

For production systems, consider these more secure patterns:

• Deploy keys with limited permissions in CI systems
• SSH certificate authority
• Vault-based temporary credential injection

Bypassing permission checks means:

• Any process on the system could read the private key
• Compromise of any user account compromises the key
• Violates common compliance frameworks

Always document these exceptions in your security policy and monitor access.

---

While developing automation systems or shared infrastructure, we occasionally face scenarios where multiple system users need access to the same private key. Normally, SSH enforces strict permission rules (600 recommended) for private keys, refusing to use them if they're group/others-readable (444 in this case).

# Typical error when permissions are too open
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
WARNING: UNPROTECTED PRIVATE KEY FILE!
Permissions 0444 for '/var/vendor/id_rsa' are too open.
This private key will be ignored.

The OpenSSH client checks permissions (via stat(2)) to prevent private key exposure. From the ssh(1) man page:

These files contain sensitive data and should be readable by the user but not accessible by others. ssh will ignore a private key file if it's accessible by others.

Option 1: SSH Configuration Override

Create a wrapper script that temporarily modifies permissions:

#!/bin/bash
ORIG_PERMS=$(stat -c "%a" /var/vendor/id_rsa)
chmod 600 /var/vendor/id_rsa
ssh -i /var/vendor/id_rsa "$@"
chmod $ORIG_PERMS /var/vendor/id_rsa

Option 2: Patching OpenSSH (Advanced)

For compiled environments, you can modify the permission check in sshkey.c:

// Comment out or modify the check in sshkey_permissions_ok()
if ((st.st_mode & 077) != 0) {
    // error("bad permissions");
    // return SSH_ERR_KEY_BAD_PERMISSIONS;
}

Option 3: Using SSH Agent Forwarding

Configure one master user with proper permissions that others can leverage:

# On the master system:
eval $(ssh-agent)
ssh-add /var/vendor/id_rsa  # Properly permissioned

Before implementing these solutions:

• Consider using SSH certificates instead of shared keys
• Implement strict auditing of key usage
• Rotate keys frequently
• Use sudo privileges carefully

For enterprise environments, consider using a dedicated service:

# Example systemd service unit
[Unit]
Description=SSH Key Proxy Service

[Service]
ExecStart=/usr/bin/socat UNIX-LISTEN:/var/run/sshproxy.sock,fork,user=sshusers,group=sshusers,mode=0660 EXEC:"/usr/bin/ssh -i /secure/vendor_key"

[Install]
WantedBy=multi-user.target