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

РЕДАКТИРОВАТЬ: вы можете найти больше информации (с несколькими ссылками) в этом вопросе 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/

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

Я немного опоздал на вечеринку, однако я предлагаю вам взглянуть на 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. Нет доступа к оболочке.

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

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

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

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

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

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

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

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