Як налаштувати ssh's umask для всіх типів з'єднань

Я шукав спосіб настройки в OpenSSH UMASK до 0027послідовним чином у всіх типах з'єднань.

За типом з'єднання я маю на увазі:

1. sftp
2. scp
3. ssh ім'я хоста
4. ssh програма імені хоста

Різниця між 3. і 4. полягає в тому, що перший запускає оболонку, яка зазвичай читає /etc/profileінформацію, а друга - ні.

Крім того, прочитавши цю публікацію, мені стало відомо про параметр -u, який присутній у нових версіях OpenSSH. Однак це не працює.

Я також повинен додати, що /etc/profileзараз включає umask 0027.

Точка за пунктом:

• SFTP - Установка -u 0027в sshd_configяк уже згадувалося тут , мало.

Якщо я не встановив цей параметр, sftp використовує за замовчуванням umask 0022. Це означає, що якщо у мене є два файли:

-rwxrwxrwx 1 user user 0 2011-01-29 02:04 execute
-rw-rw-rw- 1 user user 0 2011-01-29 02:04 read-write

Коли я використовую sftp, щоб помістити їх у машину призначення, я фактично отримую:

-rwxr-xr-x 1 user user 0 2011-01-29 02:04 execute
-rw-r--r-- 1 user user 0 2011-01-29 02:04 read-write

Однак , коли я встановив -u 0027на sshd_configмашини призначення я на самому ділі отримати:

-rwxr--r-- 1 user user 0 2011-01-29 02:04 execute
-rw-r--r-- 1 user user 0 2011-01-29 02:04 read-write

чого не очікується, оскільки це насправді має бути:

-rwxr-x--- 1 user user 0 2011-01-29 02:04 execute
-rw-r----- 1 user user 0 2011-01-29 02:04 read-write

Хтось розуміє, чому це відбувається?

• scp - незалежно від того, що налаштовано для sftp , дозволи завжди є umask 0022. Наразі я не маю уявлення, як це змінити.

• ssh ім'я хоста - тут немає жодних проблем, оскільки оболонка читається /etc/profileза замовчуванням, що означає umask 0027в поточній установці.

• Програма ssh hostname - така ж ситуація, як і scp .

Підсумовуючи, встановлення umask на sftpзміну результату, але не так, як слід, ssh hostnameпрацює як очікуване читання, /etc/profileі те, і інше, scpі, ssh hostname programздається, umask 0022десь жорстко закодовано.

Будь-яке розуміння будь-якого з вищезазначених моментів вітається.

EDIT: Я хотів би уникати патчів, які вимагають вручну компілювати opensh. У системі працює Ubuntu Server 10.04.01 (зрозумілий) LTS з opensshпакетами від maverick.

Відповідь: Як вказує poige, використання pam_umask зробило трюк.

Точні зміни були:

Рядки додаються до /etc/pam.d/sshd:

# Setting UMASK for all ssh based connections (ssh, sftp, scp)
session    optional     pam_umask.so umask=0027

Крім того, щоб вплинути на всі оболонки входу, незалежно від того, джерела вони є /etc/profileчи ні, до них також додавалися ті самі рядки /etc/pam.d/login.

EDIT : Після деяких коментарів я повторно перевірив це питання.

Принаймні, в Ubuntu (де я тестував) здається, що якщо користувач має інший umask, встановлений у файлах init своїх оболонок (.bashrc, .zshrc, ...), PAM umask ігнорується і замість нього використовується визначений користувачем umask. Зміни /etc/profileне вплинули на результат, якщо користувач не надав явних джерел цих змін у файлах init.

На даний момент незрозуміло, чи трапляється така поведінка у всіх дистрибутивах.

Я можу запропонувати спробувати 2 речі:

1. pam_umask
2. Обгортка LD_PRELOAD (самозапис?)

Ось рішення, яке дозволить вам робити те, що ви хочете, на основі кожного користувача. Він використовує лише вбудовані sshdфункції та не потребує зв'язування з локально підтримуваними патчами. Це рішення використовує ForceCommandповедінку sshd, щоб вставити сценарій настройки середовища у кожне ssh-з'єднання, а потім виконати оригінальну команду.

Спочатку створіть сценарій десь у вашій системі із наступним вмістом:

#!/bin/sh

umask 0027
exec /bin/sh -c "${SSH_ORIGINAL_COMMAND:-$SHELL}"

Для цілей цього прикладу я припускаю, що ви це називали /usr/bin/umask-wrapper.

Тепер у вас є кілька варіантів налаштування цього. Якщо ви хочете, щоб це була обов’язкова конфігурація для всіх користувачів (що здається трохи малоймовірним), ви можете змінити свою конфігурацію sshd, щоб вона включала в себе наступне:

ForceCommand /usr/bin/umask-wrapper

Якщо ви хочете, щоб це стосувалося лише деяких користувачів, ви можете використовувати Matchблок (це стосується кінця вашого sshd_config):

Match User user1,user2
ForceCommand /usr/bin/umask-wrapper

Якщо ви хочете, щоб це було керованим користувачем поведінкою, тоді ви можете використовувати command=параметр у authorized_keyфайлі, щоб вибрати цю поведінку для конкретних клавіш. Наприклад, тестуючи це, я додав у свій authorized_keysфайл запис, який виглядає приблизно так:

command="/home/lars/bin/umask-wrapper" ssh-rsa AAAAB3NzaC1 ... umask-test

Ось кілька результатів мого тесту:

Використання sshбез команди:

localhost$ ssh remotehost
remotehost$ touch umask-test/file1
remotehost$ ls -l umask-test/file1
-rw-r-----. 1 lars lars 0 Feb  2 06:02 file1

Використання sshкоманди:

localhost$ ssh remotehost touch umask-test/file2
localhost$ ssh remotehost ls -l umask-test/file2
-rw-r-----. 1 lars lars 0 Feb  2 06:03 file2

Використання scp:

localhost$ touch file3
localhost$ ls -l file3
-rw-r--r--  1 lars  staff  0 Feb  2 06:03 file3
localhost$ scp file3 remotehost:umask-test/file3
localhost$ ssh remotehost ls -l umask-test/file3
-rw-r-----. 1 lars lars 0 Feb  2 06:03 file3

Використання sftp:

localhost$ sftp remotehost
sftp> put file3 umask-test/file4
sftp> ls -l umask-test/file4
-rw-r-----    0 500      500             0 Feb  2 06:05 umask-test/file4

І там у вас є. Я вважаю, це така поведінка, яку ви шукали. Якщо у вас виникнуть запитання щодо цього рішення, я би радий надати додаткові деталі.

Я взяв дещо інший підхід до централізації обстановки.

Це було додано до /etc/pam.d/common-session:

session    optional     pam_umask.so

Це було змінено /etc/login.defs:

UMASK           0027

Я отримав pam_umask працювати з ssh, але не з scp або sftp.

Метод обгортки також нічого не робить для sftp або scp. Я не впевнений, що 027 - хороший приклад, оскільки більшість дистрибутивів уже встановили цей умаск. Спробуйте з 002 і подивіться, чи це працює.

Програми, які не встановлюють власний umask, успадковують umask програми, яка його запустила. Повністю припиніть sshd, встановіть свій umask на 0027, а потім запустіть його знову. (Ви можете додати команду umask в сценарій init для майбутніх перезавантажень.)

Тестовано для роботи з scp.

Якщо pam_umaskце не впливає на ваші сеанси SFTP, перевірте, чи UsePamвстановлено Yesу /etc/ssh/sshd_configфайлі.

Якщо ви відключили автентифікацію пароля і UsePamбуло встановлено або встановлено за замовчуванням No. Ви можете встановити ChallengeResponseAuthentication Noв sshd_configфайлі , так як в противному випадку ви можете випадково включити перевірку пароля через цю систему.

Додана примітка до відповіді користувача188737 вище:

Це може бути само собою зрозумілим, але якщо ви не використовуєте пакунок opensh-сервера , а ви склали OpenSSH вручну , переконайтеся, що ви "Увімкніть підтримку PAM", передавши --with-pamпрапор конфігурації.

Інакше UsePAM=yesв sshd_config, а також будь-які зміни, /etc/pam.d/*які фактично будуть ігноровані sshd.

Нарешті, мені зрозуміло, чому жодне з рекомендованих рішень PAM не впливало на тестування за допомогою неінтерактивних SFTP-з'єднань ...

Оскільки umask успадковується від батьківського процесу, то в системі Slackware, яка використовує /etc/rc.d/rc.sshdдля запуску / зупинки / перезавантаження sshd, ви можете просто розмістити umask 0027на рядку безпосередньо над "sshd_start" або "sshd_restart", або, як варіант, в будь-якій точці перед Основний розділ виконання починається /etc/rc.d/rc.sshd:

case "$1" in
'start')
  umask 0027
  sshd_start
  ;;
'stop')
  sshd_stop
  ;;
'restart')
  umask 0027
  sshd_restart
  ;;
*)

Або, як варіант, у верхній частині файлу:

#!/bin/sh
# Start/stop/restart the secure shell server:
umask 0027

Я щойно перевірив можливе вдосконалення параметрів srsd_config на larsks на solaris 11

Налаштуйте групу з керованими користувачами та перемістіть скрипт у сам файл конфігурації, у моєму випадку я хотів встановити umask на 0002.

отримана конфігурація стає ....

Match Group managedgroup
ForceCommand /bin/sh -c 'umask 0002; ${SSH_ORIGINAL_COMMAND:-$SHELL}'

Я боровся з цією проблемою, зокрема з дозволами на файли після копіювання файлу за допомогою scp , і нарешті мені спало на думку просто використовувати ssh для зміни дозволів після копіювання.

Ось рішення:

1. Скопіюйте свій файл: localhost$ scp filename remotehost:umask-test/filename
2. Виправити дозвіл: localhost$ ssh remotehost "chmod go+r umask-test/filename"

Найкраще, що для доступу до цього рішення не потрібен кореневий доступ.