Я запускаю сервер Ubuntu 16.04 с eCryptfs и samba.
Пользовательский bob создал зашифрованную частную папку через ecryptfs-setup-private. Кодовая фраза обертывания соответствует парольной фразе входа в систему linux. Когда bob подключается через SSH, его личная папка дешифруется автоматически. Пользователь bob имеет доступ к самбе в свой домашний каталог. Учетные данные samba соответствуют учетным данным пользователя linux.
Конфигурация PAM содержит записи по умолчанию (созданные Ubuntu и eCryptfs). /etc/fstab не содержит записей, относящихся к eCryptfs.
Когда bob обращается к своей частной папке через samba с клиента Windows, его личная папка не расшифровывается. Журнал сервера samba (/var/log/samba/some-client.log) содержит
Signature not found in user keyring
Perhaps try the interactive 'ecryptfs-mount-private'
Такое же сообщение возникает, когда bob открывает оболочку через sudo; это не происходит, когда bob открывает оболочку через su. По-видимому, пользовательский сеансовый ключ имеет различный контент в зависимости от метода входа в систему:
$ su -c 'keyctl show @s' bob
Keyring
887339582 --alswrv 1000 65534 keyring: _uid_ses.1000
797923857 --alswrv 1000 65534 \_ keyring: _uid.1000
523913245 --alswrv 1000 1000 \_ user: 363f394f32249cc4
840141489 --alswrv 1000 1000 \_ user: 905f555cf7fd10e0
$ sudo -i -H -u bob -- keyctl show @s
Signature not found in user keyring
Perhaps try the interactive 'ecryptfs-mount-private'
Keyring
887339582 --alswrv 1000 65534 keyring: _uid_ses.1000
797923857 --alswrv 1000 65534 \_ keyring: _uid.1000
Кажется, что учетные данные для входа отсутствуют в брелоке при использовании sudo.
Предполагаю, что, когда я нахожу решение для случая sudo, его можно применить к проблеме samba.
Я попытался изменить /etc/pam.d/sudo на содержимое /etc/pam.d/su, но это не повлияло. Я читал о ecryptfs-add-passphrase и pam_cifscreds, но не знаю, может ли и как один из них может быть полезен здесь. Я просмотрел вики Ubuntuusers.de и Arch Linux, нашел несколько вопросов по StackOverflow и unix.stackexchange.com (ссылки опущены из-за низкой репутации), но еще не нашли решения.
Что нужно, чтобы eCryptfs использовал учетные данные для входа в sudo случае? Что необходимо, чтобы eCryptfs использовал учетные данные для входа в дело samba?После дальнейших исследований я могу ответить на один вопрос: невозможно использовать учетные данные sudo или samba для автоматической дешифровки частной папки eCryptfs при входе в систему, потому что пароль неизвестен в любом случае.
[d2 ] 1.) [F2]Предположим, что пользовательская команда вызывает sudo -u bob. Алисе не нужен пароль Боба для этого; она использует свой собственный пароль. Таким образом, Боба невозможно и не может быть добавлен в пользовательскую брешь или использоваться eCryptfs. Это разница с su, которая требует пароля bob. Поэтому можно автоматически монтировать папку eCryptfs с su, но не с sudo.
Мое наблюдение заключалось в том, что учетные данные для входа отсутствуют в сеансовый сеанс пользователя. Я подумал, что, возможно, самба не добавляет их по умолчанию, поэтому я искал способ сделать это вручную.
После небольшого исследования я нашел модуль PAM pam_cifscreds, который может быть использован для предоставления пользовательские учетные данные для ядра - звучит хорошо. Я добавил pam_cifscreds.so в оба объекта PAM auth (чтобы сохранить пароль в брелоке) и session, но не повезло. С набором аргументов debug, вызов session написал сообщение no stored password found в журнал; вызов auth не был виден.
Дальнейшие исследования привели меня к другому модулю PAM pam_script и его примерному файлу logscript, который может использоваться для отслеживания вызовов PAM. Он показал, что средство session вызывается на каждом подключении клиента samba, но средство auth отсутствует. Затем я нашел этот абзац в конфигурации smb.conf PAM:
Samba всегда игнорирует PAM для аутентификации в случае шифрования паролей = да. Причина в том, что модули PAM не могут поддерживать механизм аутентификации вызова / ответа, необходимый при наличии шифрования паролей SMB.В настоящее время клиент samba не отправляет пароль clear-text, а хэш-значение на сервер. Таким образом, сервер не имеет доступа к паролю и не может добавить его в брелок.
Возможно, возможно изменить конфигурацию samba, чтобы разрешить использование текстовых паролей, но я не хочу этого и, следовательно,
Мое представление о прозрачном расшифровке на стороне сервера на основе учетных данных пользователя samba невозможно, поскольку на сервере отсутствует пароль.
В качестве обходного пути может быть другой вариант: если eCryptfs не использовал один файл wrapped-passphrase, а один для каждого типа входа (например, пароль UNIX, сертификат Samba, SSH, ...), монтажная кодовая фраза может быть распакована в зависимости от при входе в систему. Но поскольку реализация этой идеи кажется довольно сложной и отнимающей много времени для меня, я не буду отслеживать ее дальше.
После дальнейших исследований я могу ответить на один вопрос: невозможно использовать учетные данные sudo или samba для автоматической дешифровки частной папки eCryptfs при входе в систему, потому что пароль неизвестен в любом случае.
Предположим, что пользовательская команда вызывает sudo -u bob. Алисе не нужен пароль Боба для этого; она использует свой собственный пароль. Таким образом, Боба невозможно и не может быть добавлен в пользовательскую брешь или использоваться eCryptfs. Это разница с su, которая требует пароля bob. Поэтому можно автоматически монтировать папку eCryptfs с su, но не с sudo.
Мое наблюдение заключалось в том, что учетные данные для входа отсутствуют в сеансовый сеанс пользователя. Я подумал, что, возможно, самба не добавляет их по умолчанию, поэтому я искал способ сделать это вручную.
После небольшого исследования я нашел модуль PAM pam_cifscreds, который может быть использован для предоставления пользовательские учетные данные для ядра - звучит хорошо. Я добавил pam_cifscreds.so в оба объекта PAM auth (чтобы сохранить пароль в брелоке) и session, но не повезло. С набором аргументов debug, вызов session написал сообщение no stored password found в журнал; вызов auth не был виден.
Дальнейшие исследования привели меня к другому модулю PAM pam_script и его примерному файлу logscript, который может использоваться для отслеживания вызовов PAM. Он показал, что средство session вызывается на каждом подключении клиента samba, но средство auth отсутствует. Затем я нашел этот абзац в конфигурации smb.conf PAM:
Samba всегда игнорирует PAM для аутентификации в случае шифрования паролей = да. Причина в том, что модули PAM не могут поддерживать механизм аутентификации вызова / ответа, необходимый при наличии шифрования паролей SMB.В настоящее время клиент samba не отправляет пароль clear-text, а хэш-значение на сервер. Таким образом, сервер не имеет доступа к паролю и не может добавить его в брелок.
Возможно, возможно изменить конфигурацию samba, чтобы разрешить использование текстовых паролей, но я не хочу этого и, следовательно,
Мое представление о прозрачном расшифровке на стороне сервера на основе учетных данных пользователя samba невозможно, поскольку на сервере отсутствует пароль.
В качестве обходного пути может быть другой вариант: если eCryptfs не использовал один файл wrapped-passphrase, а один для каждого типа входа (например, пароль UNIX, сертификат Samba, SSH, ...), монтажная кодовая фраза может быть распакована в зависимости от при входе в систему. Но поскольку реализация этой идеи кажется довольно сложной и отнимающей много времени для меня, я не буду отслеживать ее дальше.
После дальнейших исследований я могу ответить на один вопрос: невозможно использовать учетные данные sudo или samba для автоматической дешифровки частной папки eCryptfs при входе в систему, потому что пароль неизвестен в любом случае.
Предположим, что пользовательская команда вызывает sudo -u bob. Алисе не нужен пароль Боба для этого; она использует свой собственный пароль. Таким образом, Боба невозможно и не может быть добавлен в пользовательскую брешь или использоваться eCryptfs. Это разница с su, которая требует пароля bob. Поэтому можно автоматически монтировать папку eCryptfs с su, но не с sudo.
Мое наблюдение заключалось в том, что учетные данные для входа отсутствуют в сеансовый сеанс пользователя. Я подумал, что, возможно, самба не добавляет их по умолчанию, поэтому я искал способ сделать это вручную.
После небольшого исследования я нашел модуль PAM pam_cifscreds, который может быть использован для предоставления пользовательские учетные данные для ядра - звучит хорошо. Я добавил pam_cifscreds.so в оба объекта PAM auth (чтобы сохранить пароль в брелоке) и session, но не повезло. С набором аргументов debug, вызов session написал сообщение no stored password found в журнал; вызов auth не был виден.
Дальнейшие исследования привели меня к другому модулю PAM pam_script и его примерному файлу logscript, который может использоваться для отслеживания вызовов PAM. Он показал, что средство session вызывается на каждом подключении клиента samba, но средство auth отсутствует. Затем я нашел этот абзац в конфигурации smb.conf PAM:
Samba всегда игнорирует PAM для аутентификации в случае шифрования паролей = да. Причина в том, что модули PAM не могут поддерживать механизм аутентификации вызова / ответа, необходимый при наличии шифрования паролей SMB.В настоящее время клиент samba не отправляет пароль clear-text, а хэш-значение на сервер. Таким образом, сервер не имеет доступа к паролю и не может добавить его в брелок.
Возможно, возможно изменить конфигурацию samba, чтобы разрешить использование текстовых паролей, но я не хочу этого и, следовательно,
Мое представление о прозрачном расшифровке на стороне сервера на основе учетных данных пользователя samba невозможно, поскольку на сервере отсутствует пароль.
В качестве обходного пути может быть другой вариант: если eCryptfs не использовал один файл wrapped-passphrase, а один для каждого типа входа (например, пароль UNIX, сертификат Samba, SSH, ...), монтажная кодовая фраза может быть распакована в зависимости от при входе в систему. Но поскольку реализация этой идеи кажется довольно сложной и отнимающей много времени для меня, я не буду отслеживать ее дальше.
Это давняя ошибка
https://bugs.launchpad.net/ecryptfs/+bug/277578
ecryptfs не работает должным образом над nfs, cifs, samba , WebDAV или aufsВременное решение - используйте sshfs: https://bugs.launchpad.net/ecryptfs/+bug/277578
Другие варианты: Введите отчет об ошибке re: sudo / su, если хотите.
Это давняя ошибка
https://bugs.launchpad.net/ecryptfs/+bug/277578
ecryptfs не работает должным образом над nfs, cifs, samba , WebDAV или aufsВременное решение - используйте sshfs: https://bugs.launchpad.net/ecryptfs/+bug/277578
Другие варианты: Введите отчет об ошибке re: sudo / su, если хотите.
Это давняя ошибка
https://bugs.launchpad.net/ecryptfs/+bug/277578
ecryptfs не работает должным образом над nfs, cifs, samba , WebDAV или aufsВременное решение - используйте sshfs: https://bugs.launchpad.net/ecryptfs/+bug/277578
Другие варианты: Введите отчет об ошибке re: sudo / su, если хотите.