Принудительно заставить ssh игнорировать права доступа id_rsa

У меня есть очень специфическое требование, которое требует, чтобы закрытый ключ использовался несколькими пользователями. Я знаю, насколько это плохо. Проблема в том, что если разрешения на файл идентификации слишком открытые (444 в моем случае), ssh просто их игнорирует.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @        
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.

Из руководства man

Содержит закрытый ключ для аутентификации. Эти файлы содержат
конфиденциальные данные и должны быть читаемы пользователем, но не доступны
другим лицам (чтение/запись/выполнение). ssh просто проигнорирует файл
закрытого ключа, если он доступен другим лицам.

Есть ли способ заставить ssh использовать ключ без проверки разрешений?

Как упоминалось в других ответах, похоже, что нет способа заставить SSH игнорировать эту опцию. Проверка происходит в функции authfile.c 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;
}

Если изменение разрешений файла ключа не является вариантом, решение заключается в том, чтобы загрузить исходный код OpenSSH, удалить эту проверку из кода и пересобрать его.

Ответ на связанный вопрос предполагает, что нет способа обойти проверку разрешений.

Однако у меня была та же проблема –
я хотел, чтобы несколько пользователей делились одним и тем же ключом, чтобы иметь возможность доступа и управления большой группой хостов –
и мое решение может быть полезным другим.

Вот что я сделал:

1. Создайте специального пользователя (скажем, master) и группу (master) для хранения ключа.
2. Создайте/сохраните файлы ключей в ~master/.ssh/.
3. Дайте группе права на чтение файла ключа, chmod g+r ~master/.ssh/id_rsa.
4. Добавьте каждого из авторизованных пользователей в группу master.
5. Создайте ссылку из ~user/.ssh/id_rsa в ~master/.ssh/id_rsa.

Это позволяет авторизованному пользователю использовать ssh без проблем,
но предотвращает открытие ключа для всех.
Кроме того, владелец ключа не является root.

Странно, но сам пользователь master все еще будет получать предупреждение “закрытый ключ небезопасен”.
Это можно обойти, изменив владельца (но не группу) файла ключа на какого-то специального пользователя, который никогда не будет использовать ключ,
например sudo chown daemon ~master/.ssh/id_rsa.

Вы можете сделать его доступным для чтения с помощью списков управления доступом. Используйте утилиты getfacl и setfacl.

Не забудьте также установить правильно маску с помощью setfacl, потому что обычно любые отдельные разрешения, которые вы добавите, не будут эффективными, если разрешения для группы не такие же.

Ваша файловая система должна поддерживать это. Если она не включена, вам нужно добавить опцию монтирования в ваш fstab.

Как все предполагают, нет способа обойти проверки безопасности.

Но вы можете создать копию ключа и изменить разрешения на этой копии:

# Скопируйте ваш ключ в новое место
cp <<your_key>> <<new_key>>

# Убедитесь, что вы являетесь владельцем
chown <<your_user>>:<<your_user>> <<new_key>>

# Дайте себе полные разрешения, удалив весь доступ для других
chmod 700 <<new_key>>

Это сработало для меня.

Комментарий от @João Rodrigues к ответу от @Andrei Savin в конце дает мне подсказку о использовании sudo:

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

Следующие сообщения об ошибках (примеры)

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).

могут быть проигнорированы. Это работает из коробки с использованием Debian Buster (OpenSSH_7.9p1, OpenSSL 1.1.1d) и MacOS Big Sur (OpenSSH_8.1p1, LibreSSL 2.7.3).

Предложение с другой точки зрения:

SSH работает с файлом (обычно ~/.ssh/authorized_keys, если у вас есть доступ к файловой системе сервера), чтобы решить, какие пары ключей разрешено использовать для учетной записи.

Если вы можете отредактировать этот файл, просто добавьте открытый ключ от каждого пользователя в этот файл для соответствующей учетной записи, и все они смогут заходить в нее. Если кто-то увольняется или меняет должностные обязанности, удалите его открытый ключ из файла.

Мне нужно было решение для случая, когда я не мог изменять или создавать файлы, но мог немного изменить способ загрузки закрытого ключа.

Перенаправление файла ключа в stdin также является решением:

ssh-add - <"$SSH_PRIVATE_KEY_FILE"

Предыстория:
Мой конкретный случай использования заключается в том, что у меня есть SSH-закрытый ключ в Vault, и я загружаю его внутри GitLab pipeline как файл. К сожалению, GitLab создает такие секретные файлы с разрешениями 0666.