Как установить каталог eCryptfs на доступ к samba?

Среда

Я запускаю сервер 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?
0
задан 16 August 2017 в 20:21

6 ответов

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

[d2 ] 1.) [F2]

Предположим, что пользовательская команда вызывает sudo -u bob. Алисе не нужен пароль Боба для этого; она использует свой собственный пароль. Таким образом, Боба невозможно и не может быть добавлен в пользовательскую брешь или использоваться eCryptfs. Это разница с su, которая требует пароля bob. Поэтому можно автоматически монтировать папку eCryptfs с su, но не с sudo.

2.) Samba

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

После небольшого исследования я нашел модуль 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, ...), монтажная кодовая фраза может быть распакована в зависимости от при входе в систему. Но поскольку реализация этой идеи кажется довольно сложной и отнимающей много времени для меня, я не буду отслеживать ее дальше.

0
ответ дан 22 May 2018 в 19:23

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

1.) [F2]

Предположим, что пользовательская команда вызывает sudo -u bob. Алисе не нужен пароль Боба для этого; она использует свой собственный пароль. Таким образом, Боба невозможно и не может быть добавлен в пользовательскую брешь или использоваться eCryptfs. Это разница с su, которая требует пароля bob. Поэтому можно автоматически монтировать папку eCryptfs с su, но не с sudo.

2.) Samba

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

После небольшого исследования я нашел модуль 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, ...), монтажная кодовая фраза может быть распакована в зависимости от при входе в систему. Но поскольку реализация этой идеи кажется довольно сложной и отнимающей много времени для меня, я не буду отслеживать ее дальше.

0
ответ дан 18 July 2018 в 08:25

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

1.) [F2]

Предположим, что пользовательская команда вызывает sudo -u bob. Алисе не нужен пароль Боба для этого; она использует свой собственный пароль. Таким образом, Боба невозможно и не может быть добавлен в пользовательскую брешь или использоваться eCryptfs. Это разница с su, которая требует пароля bob. Поэтому можно автоматически монтировать папку eCryptfs с su, но не с sudo.

2.) Samba

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

После небольшого исследования я нашел модуль 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, ...), монтажная кодовая фраза может быть распакована в зависимости от при входе в систему. Но поскольку реализация этой идеи кажется довольно сложной и отнимающей много времени для меня, я не буду отслеживать ее дальше.

0
ответ дан 24 July 2018 в 19:05

Это давняя ошибка

https://bugs.launchpad.net/ecryptfs/+bug/277578

ecryptfs не работает должным образом над nfs, cifs, samba , WebDAV или aufs

Временное решение - используйте sshfs: https://bugs.launchpad.net/ecryptfs/+bug/277578

Другие варианты: Введите отчет об ошибке re: sudo / su, если хотите.

1
ответ дан 22 May 2018 в 19:23
  • 1
    С моей точки зрения, зарегистрированная ошибка здесь не применяется. Он описывает crash , когда Samba, CIFS или NFS используется как , лежащая в основе файловой системы (которая содержит частную папку). Здесь не так. Я должен придерживаться samba, потому что все клиенты поддерживают его изначально, поэтому использование sshfs в качестве альтернативы не является вариантом. – Christian 17 August 2017 в 07:31
  • 2
    @Christian Затем файл новый отчет об ошибке =) – Panther 17 August 2017 в 21:21

Это давняя ошибка

https://bugs.launchpad.net/ecryptfs/+bug/277578

ecryptfs не работает должным образом над nfs, cifs, samba , WebDAV или aufs

Временное решение - используйте sshfs: https://bugs.launchpad.net/ecryptfs/+bug/277578

Другие варианты: Введите отчет об ошибке re: sudo / su, если хотите.

1
ответ дан 18 July 2018 в 08:25

Это давняя ошибка

https://bugs.launchpad.net/ecryptfs/+bug/277578

ecryptfs не работает должным образом над nfs, cifs, samba , WebDAV или aufs

Временное решение - используйте sshfs: https://bugs.launchpad.net/ecryptfs/+bug/277578

Другие варианты: Введите отчет об ошибке re: sudo / su, если хотите.

1
ответ дан 24 July 2018 в 19:05
  • 1
    С моей точки зрения, зарегистрированная ошибка здесь не применяется. Он описывает crash , когда Samba, CIFS или NFS используется как , лежащая в основе файловой системы (которая содержит частную папку). Здесь не так. Я должен придерживаться samba, потому что все клиенты поддерживают его изначально, поэтому использование sshfs в качестве альтернативы не является вариантом. – Christian 17 August 2017 в 07:31
  • 2
    @Christian Затем файл новый отчет об ошибке =) – Panther 17 August 2017 в 21:21

Другие вопросы по тегам:

Похожие вопросы: