Назад | Перейти на главную страницу

Разрешить SCP, но не фактический вход, используя SSH

Есть ли способ настроить пользователя в Linux (в данном случае Centos 5.2), чтобы он мог использовать scp для извлечения файлов, но не мог войти на сервер с помощью SSH?

rssh оболочка (http://pizzashack.org/rssh/) предназначен именно для этой цели.

Поскольку RHEL / CentOS 5.2 не включает пакет для rssh, вы можете посмотреть здесь, чтобы получить RPM: http://dag.wieers.com/rpm/packages/rssh/

Чтобы использовать его, просто установите его как оболочку для нового пользователя, например:

useradd -m -d /home/scpuser1 -s /usr/bin/rssh scpuser1
passwd scpuser1

..или изменить оболочку на уже существующую, например:

chsh -s /usr/bin/rssh scpuser1

..и редактировать /etc/rssh.conf для настройки rssh shell - особенно раскомментируйте allowscp строка, чтобы разрешить доступ к SCP для всех пользователей rssh.

(Вы также можете использовать chroot, чтобы держать пользователей в своих домах, но это уже другая история.)

Я опаздываю к этому, но вы можете использовать ключи ssh и указать точную команду, разрешенную в их файле ~ / .ssh / authorized_keys, например.

no-port-forwarding, no-pty, command = "исходная цель scp" ssh-dss ...

Возможно, вам понадобится использовать ps to на цели, чтобы установить правильные настройки команды.

PS: Если вы запустите тестовую команду scp с "-v", вы увидите что-то вроде этого

debug1: Sending command: scp -v -t myfile.txt

Вы заметите, что «-t» - это недокументированная опция scp, используемая программой на дальнем конце. Это дает вам представление о том, что вам нужно поместить в authorized_keys.

РЕДАКТИРОВАТЬ: Вы можете найти более подробную информацию (с несколькими ссылками) в этот вопрос StackOverflow.

Вот рабочий пример этого для пользователя с именем backup_user на стороне сервера.

~backup_user/.ssh/authorized_keys контент на стороне сервера (с некоторыми дополнительными ограничениями безопасности):

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="scp -v -r -d -t ~/CONTENT" ssh-rsa AAAAMYRSAKEY...

Создайте в ~ backup_user / ссылку на каталог, в котором должно быть доступно содержимое.

$ ln -s /path/to/directory/with/accessible/content ~backup_user/CONTENT

Теперь со стороны клиента должна работать следующая команда:

scp -v  -r  -P 2222 -i .ssh/id_rsa_key_file path/to/data backup_user@SERVER:~/CONTENT

Что делает эта команда:

  • Отображает подробную информацию (необязательный: вы можете удалить -v из файла command и authorized_keys)
  • Он рекурсивно копирует содержимое пути / к / данным. (необязательный: вы можете удалить -r из файла command и authorized_keys, если вы не хотите делать рекурсивную копию)
  • Он использует порт 2222 для подключения к серверу (необязательный: вы можете удалить -P 2222 из команды)
  • Он использует файл идентификации для автоматизации подключения (необязательный: вы можете удалить -i .ssh/id_rsa_key_file
  • Содержание path/to/data будет скопирован в /path/to/directory/with/accessible/content/

Чтобы сделать копию файла (или нескольких) с сервера на клиент, вы должны создать сценарий оболочки, который обрабатывает это как описано здесь

Я немного опоздал на вечеринку, однако предлагаю вам взглянуть на ForceCommand директива OpenSSH.

Subsystem sftp internal-sftp

Match group sftponly
         ForceCommand internal-sftp

Конечно, это SFTP, а не SCP, но он достигает той же цели, но более безопасно, чем с помощью оболочки с ограничениями. Кроме того, вы можете заблокировать пользователя, если хотите.

Я бы рекомендовал использовать scponly.

Это ограниченная оболочка, которая позволяет пользователям делать то, что они звучат, файлы SCP на сервере, но фактически не входить в систему. Доступна загрузка информации и исходного кода для программного обеспечения Вот а предварительно скомпилированные пакеты RPM доступны через EPEL YUM Репозитории.

После установки вам необходимо настроить каждую учетную запись пользователя, доступ к которой вы хотите ограничить, для использования только что установленной оболочки с ограничениями. Вы можете сделать это вручную через / etc / passwd или использовать следующую команду: usermod -s /usr/bin/scponly USERNAME

Для этого я использую MySecureShell. Вы также можете настроить другие ограничения.

https://github.com/mysecureshell/mysecureshell

Ограничивает подключения только к SFTP / SCP. Нет доступа к оболочке.

Очень поздно для вечеринки, но просто установите оболочку пользователя git на / usr / bin / git-shell. Это ограниченная оболочка, которая не позволяет интерактивный вход. Вы по-прежнему можете подключиться к пользователю с помощью su -s / bin / bash git или любого другого имени пользователя git.

Мы используем псевдоболочку под названием scponly на наших защищенных ftp-серверах для пользователей мы хотим иметь возможность только scp-файлов, но не авторизоваться.

Я нашел хороший способ - использовать функцию command = "..." файла authorized_keys. (Предложено мне эта страница)

Команда, которую вы запустите, будет проверять аргументы, начинающиеся с scp (и rsync).

Вот файл authorized_keys:

# authorized_keys
command="/usr/local/bin/remote-cmd.sh" ssh-rsa.....== user@pewpew

Вот содержимое remote-cmd.sh:

#!/bin/bash
# /usr/local/bin/remote-cmd.sh
case $SSH_ORIGINAL_COMMAND in
 'scp'*)
    $SSH_ORIGINAL_COMMAND
    ;;
 'rsync'*)
    $SSH_ORIGINAL_COMMAND
    ;;
 *)
    echo "Access Denied"
    ;;
esac

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

Измените оболочку входа пользователя на что-то ограничительное, что позволяет пользователю запускать только scp, sftp-сервер и rsync только, а также проверяет, что небезопасные аргументы не разрешены (например, scp -S ... и rsync -e ... небезопасны, см. здесь: http://exploit-db.com/exploits/24795). Пример такой ограничительной оболочки входа:

  • rssh
  • scponly (не только scp, также позволяет sftp, svn и т. д., если так настроено)
  • transfer_shell

Вы можете захотеть запустить один из них в chroot или в другой ограниченной среде (например, nsjail в Linux), чтобы отключить доступ к сети и упростить (занесение в белый список) контроль над тем, какие каталоги можно читать и / или писать.

Я не рекомендую использовать command="..." в ~/.ssh/authorized_keys, потому что без тщательной дополнительной защиты (например, chmod -R u-w ~ для пользователя) злоумышленник может загрузить новую версию ~/.ssh/authorized_keys, ~/.ssh/rc или ~/.bashrc, и, таким образом, может включать и выполнять произвольные команды.

Это не самое изящное решение, но вы можете бросить что-то подобное пользователям .bashrc 

if [ "$TERM"  != "dumb" ]; then
  exit
fi

Я обнаружил, что пользователи SCP получают СРОК «тупой», а другие обычно получают vt100.

Я предполагаю, что пользователь, вероятно, мог бы scp поверх нового .bashrc, что делает это не лучшим решением, но для быстрого и грязного решения это сработает