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

62

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

DrStalker
источник
Я попытался установить оболочку входа в систему / bin / false, но это просто перестает работать scp.
DrStalker

Ответы:

45

Оболочка 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 - особенно раскомментируйте allowscpстроку, чтобы разрешить доступ SCP для всех пользователей rssh.

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

анонимное
источник
это потрясающе - я тоже некоторое время искал что-то подобное
Уоррен
6
Идея, лежащая в основе rssh, хороша, но iirc rssh не был просто чудом безопасности с точки зрения программирования. Простой Google на «rssh exploit» дает больше результатов, чем мне удобно ...
wzzrd
7
scponly более или менее то же самое , как хорошо , и по- видимому , менее подвиги склонные: sublimation.org/scponly/wiki/index.php/Main_Page
Франсуа Feugeas
кажется, что scponly переехал в github. Ссылка на сублимацию не работает. github.com/scponly/scponly/wiki
спазм
38

Я слишком поздно к этому, но вы можете использовать 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, используемая программой на дальнем конце. Это дает вам представление о том, что вам нужно поместить в авторизованные ключи.

РЕДАКТИРОВАТЬ: вы можете найти больше информации (с несколькими ссылками) в этом вопросе 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из команды, так и из файла author_keys )
  • Он рекурсивно копирует содержимое пути / к / данным. ( опция : вы можете удалить -rкак из команды, так и из файла author_keys, если вы не хотите делать рекурсивную копию)
  • Для подключения к серверу используется порт 2222 ( опция : вы можете удалить -P 2222из команды)
  • Он использует и идентификационный файл для автоматизации соединения ( опция : вы можете удалить-i .ssh/id_rsa_key_file
  • Содержание path/to/dataбудет скопировано в/path/to/directory/with/accessible/content/

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

Сообщество
источник
1
Что может помешать пользователю просматривать свой файл author_keys? Может ли быть ограничено, что он не будет принадлежать самому пользователю?
Дан
1
@Dan - Должно быть возможно установить права только для чтения для файла авторизованного ключа, т.е. chmod 400 ~/.ssh/authorized_keys,
Роджер Дуек
Также вы должны сделать ~/.bashrc(и все остальное, что выполняет Bash) и ~/.ssh/rcтолько для чтения. Но если злонамеренный пользователь имеет доступ к rsync или sftp, он все равно может удалить его ~/.bashrcи загрузить новый. Так как это трудно защитить, я рекомендую против этого метода ( command="...").
PTS
31

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

Subsystem sftp internal-sftp

Match group sftponly
         ForceCommand internal-sftp

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

Франсуа Феже
источник
2
добавьте раздел «после» chrootDirectory %hи « AllowTcpForwarding noпосле», чтобы заставить пользователей sftponly выполнить поиск в своем доме. обратите внимание, что совпадение должно (должно быть!) быть последним разделом в конфигурации ssh, и параметры после этого являются параметрами только для соответствующих пользователей
higuita
4
ForceCommand internal-sftp -u 0077 -d /uploaddirможет еще более укрепить его, форсируя umask в каталоге загрузки. Вместе с ChrootDirectory он создает очень контролируемую изолированную среду загрузки. Бонус: по умолчанию dir и umask должны быть указаны ForceCommandв Subsystemдирективе, а не в директиве, если вы хотите, чтобы они работали.
Марчин
Более длинная статья, объясняющая это, доступна на debian-administration.org/article/590/…
koppor
7

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

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

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

син-
источник
Я второй это. scponlyРазработан именно для этой цели.
UtahJarhead
1
кажется, что scponly мертв. Похоже, что debian удалил его: packages.debian.org/search?keywords=scponly, и код на github тоже мертв. Последующее обсуждение: serverfault.com/questions/726519/…
koppor
6

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

https://github.com/mysecureshell/mysecureshell

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

J.Zimmerman
источник
3

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

Ян Эллис
источник
2

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

Zypher
источник
2

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

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

Вот файл author_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

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

Фил
источник
3
Это довольно круто - но я думаю, что это можно подорвать, введя команду, которая выполняет scp, а затем запустит скрипт!
Давидго
@davidgo, добавив $ SSH_ORIGINAL_COMMAND с exec, может устранить эту уязвимость, предполагая, что scp и rsync сами не пытаются запускать несколько программ (в этом случае это сломает)
Фил
Кроме того, вы должны сделать ~/.ssh/authorized_keys, ~/.bashrc(и все остальное Bash выполняет) и ~/.ssh/rcтолько для чтения для пользователя. Но если злонамеренный пользователь имеет доступ к rsync или sftp, он все равно может удалить его ~/.bashrcи загрузить новый. Так как это трудно защитить, я рекомендую против этого метода ( command="...").
PTS
1
@pts, вы можете сделать как файлы rc, так и каталоги, содержащие их, принадлежащими кому-то, кроме пользователя (никто?) и недоступными для записи пользователем. Но в этот момент вам лучше использовать что-то вроде rssh. Вау, я только что понял, что это мой ответ! Это старый! Ха - ха!
Фил
Не забывайте, что scp -S ... и rsync -e ... позволяют пользователю выполнять произвольные команды. Поэтому вы должны проверить аргументы в $ SSH_ORIGINAL_COMMAND перед его выполнением. Более подробная информация здесь: exploit-db.com/exploits/24795
PTS
1

Измените оболочку входа пользователя на что-то ограничительное, что позволяет пользователю запускать только scp , sftp-server и 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, и , таким образом , может включать в себя и выполнять произвольные команды.

PTS
источник
0

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

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

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

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

jizaymes
источник
1
Я настоятельно рекомендую против этого предложенного решения, чтобы злоумышленнику было слишком легко обойти (например, загрузив другое ~/.bashrc). Это также странно в том смысле, что, возможно, более новые версии OpenSSH установят TERMпеременную по-другому, или могут повлиять некоторые параметры конфигурации sshd TERM.
PTS
1
Эххх ... ssh -o SetEnv TERM=dumb yourserver bash??
Улидько