У меня есть очень конкретное требование, которое требует, чтобы закрытый ключ использовался несколькими пользователями. Я знаю, как это плохо. Проблема в том, что если разрешение файла идентификации является разрешающим (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.
Со страниц руководства
Содержит закрытый ключ для аутентификации. Эти файлы содержат конфиденциальные данные и должны быть доступны для чтения пользователем, но не доступны для других (чтение / запись / выполнение). 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, удалить эту проверку из кода и перестроить его.
Вы можете сделать его доступным для рейдов с помощью списков контроля доступа. Используйте утилиты getfacl и setfacl.
Не забудьте также установить правильную маску с setfacl, потому что обычно любые отдельные разрешения, которые вы добавляете, не будут эффективны, если разрешения группы не совпадают.
Однако ваша файловая система должна его поддерживать. Если он не включен, вам нужно добавить опцию монтирования в свой fstab.
An ответ на связанный вопрос предполагает, что нет способа обойти проверку разрешений.
Однако у меня была та же проблема - я хотел, чтобы несколько пользователей использовали один и тот же ключ, чтобы иметь возможность получать доступ и управлять большой группой хостов - и мое исправление могло быть полезно другим.
Вот что я сделал:
master) и группа (master) держать ключ.~master/.ssh/.chmod g+r ~master/.ssh/id_rsa.master группа.~user/.ssh/id_rsa к ~master/.ssh/id_rsa.Это позволяет авторизованному пользователю ssh без проблем, но не дает каждому открыть ключ. Кроме того, владелец ключа не root.
Как ни странно, master сам пользователь по-прежнему будет получать предупреждение «незащищенный закрытый ключ». Этого можно избежать, изменив владельца (но не группу) ключевого файла на какого-то специального пользователя, которому никогда не понадобится использовать ключ, sudo chown daemon ~master/.ssh/id_rsa, например.
Предложение с другой точки зрения:
SSH работает с файлом (обычно ~ / .ssh / authorized_keys, если у вас есть доступ к файловой системе сервера), чтобы решить, какие пары ключей разрешить использовать для учетной записи.
Если вы можете редактировать этот файл, просто добавьте открытый ключ от каждого пользователя в этот файл для соответствующей учетной записи, и всем им будет разрешено войти в эту учетную запись. Если кто-то увольняется или меняет описание должности, удалите его pubkey из файла.