Дозволити 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 / санкціонованих_кейсів, наприклад

no-port-forwarding, no-pty, command = "scp source target" ssh-dss ...

Можливо, вам потрібно буде використовувати ps для цілі, щоб встановити правильні параметри команди.

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файл із командного та дозволеного ключів )
• Він рекурсивно копіює вміст шляху / до / даних. ( опціонально : ви можете видалити -rз файлу команд і авторизованих ключів, якщо ви не хочете робити рекурсивну копію)
• Для підключення до сервера використовується порт 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.

На наших захищених ftp-серверах ми використовуємо оболонку psudo, яку називають scponly, для користувачів, які ми хочемо лише мати можливість сканувати файли, але не входити в систему.

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

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

Ось файл із дозволеними ключами:

# 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

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

Змініть оболонку входу користувача на щось обмежувальне, що дозволяє користувачеві запускати лише 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.

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