Ограничить резервное копирование без пароля с SFTP

Мне нужно выполнить резервное копирование сервера на мой компьютер, используя Duplicity:

duplicity /etc sftp://backup@my.dynamic.ip.address//home/backup

Прежде чем это сделать, мне нужно разрешить доступ без пароля, выполнив следующие действия:

$ ssh-keygen
$ ssh-copy-id backup@my.dynamic.ip.address
$ ssh backup@my.dynamic.ip.address

У меня вопрос, как я могу ограничить команду только этой передачей SFTP в открытом ключе, который генерируется?

command="restrict to sftp",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAA…

И поскольку я нахожусь на динамическом IP-адресе, как мне преодолеть проблему «пропущенного известного хоста» каждый раз, когда мой IP-адрес изменяется?

Вопрос 1

У меня вопрос, как я могу ограничить команду только этой передачей SFTP в открытом ключе, который генерируется?

Есть 2 способа сделать это.

1. - Ограничение через sshd

Этот метод включает в себя настройку функции SFTP в пределах вашего SSH - демона, sshd. Это контролируется через /etc/ssh/sshd_configфайл конфигурации. ПРИМЕЧАНИЕ. Это ограничит пользователя, backupчтобы ему был разрешен только SFTP на сервер.

# /etc/ssh/sshd_config

Subsystem       sftp    internal-sftp

## You want to put only certain users (i.e users who belongs to sftpusers 
## group) in the chroot jail environment. Add the following lines at the end 
## of /etc/ssh/sshd_config

Match User backup
  ForceCommand internal-sftp

2. - Ограничение авторизованными ключами

Этот метод не предусматривает никаких изменений в sshd_configфайле. Вы можете ограничить пользователя + ключ SSH одной командой с помощью command=функции, которую вы уже упомянули в своем вопросе. Хитрость в том, какую команду вы включаете. Вы можете поместить SFTP-сервер в эту command=строку, что имеет тот же эффект, что и настройка SFTP-сервера в вашем sshd_configфайле.

# User backup's $HOME/.ssh/authorized_keys file
command="/usr/libexec/openssh/sftp-server" ssh-dss AAAAC8ghi9ldw== backup@host

ПРИМЕЧАНИЕ: если у пользователя есть доступ для записи ~/.ssh/authorized_keys, он может читать и / или изменять его. Например, они могли загрузить его, отредактировать и повторно загрузить, удалив его commmand=..., предоставив ему свободный доступ к командам, включая оболочку. Если у пользователя есть доступ для записи ~/.ssh, он также может просто отсоединить и заново создать файл или chmodдоступ для записи. Существует множество возможных решений, таких как размещение ~/.ssh/authorized_keysфайлов в недоступном для записи месте, например, с помощью:

Match Group sftponly
    AuthorizedKeysFile      /etc/ssh/authorized_keys/%u

Вопрос 2

И поскольку я нахожусь на динамическом IP-адресе, как мне преодолеть проблему «пропущенного известного хоста» каждый раз, когда мой IP-адрес изменяется?

Это сложнее, но выполнимо, используя from=функцию в authorized_keysфайле. Здесь мы ограничиваем доступ только с хоста somehost.dyndns.org.

from = "somehost.dyndns.org", command = "/ usr / libexec / openssh / sftp-server", переадресация без порта, пересылка без X11, переадресация без агента, no-pty ssh-dss AAAAC8ghi9ldw == резервная копия @ хост

Дополнительные параметры после command=не менее важны, поскольку они еще больше ограничат использование ключа SSH.

разбивка функций

• from='hostname1,hostname2,'' - Ограничивает доступ с указанных шаблонов IP или имени хоста
• command='command' - запускает указанную команду после аутентификации
• no-pty - не выделяет pty (не разрешает интерактивный вход в систему)
• no-port-forwarding - не позволяет переадресацию портов
• no-X11-forwarding - пользователь не сможет удалить отображаемые графические интерфейсы X11
• no-agent-forwarding - пользователь не сможет пересылать через этот хост на другие внутренние хосты

Чтобы избавиться от сообщения об «отсутствующих известных хостах», вы можете добавить эту опцию SSH к клиенту, когда он подключается так:

$ ssh -o StrictHostKeyChecking=no ....

Смотрите man-страницу, ssh_configдля получения полной информации об этом переключателе.

Ограничение пользовательской оболочки

Для обоих вышеупомянутых решений вы, вероятно, захотите заблокировать backupпользователя, ограничив также оболочку этого пользователя в /etc/passwdфайле. Обычно вы хотите установить его на scponly, но есть и другие варианты для этого. Посмотрите U & L Q & A под названием: « Вам нужна оболочка для SCP? », Чтобы узнать, как это сделать.

Использование /sbin/nologinтакже может быть использовано, если вы решили использовать функцию chroot, sshd_configкак описано в # 1 выше. Однако, если вы решите использовать метод, описанный в # 2 , вам, вероятно, придется использовать scponlyили что-то еще для оболочки пользователя /etc/passwd.

БОНУС - Расширение # 2 выше

Если вам нужно предоставить набор команд для этого пользователя, вы также можете сделать это. Создайте скрипт так /home/backup/commands.sh:

#!/bin/sh

case $SSH_ORIGINAL_COMMAND in
  "diskspace")
    df -h
    ;;
  "dirlist")
    ls -1
    ;;
  "apache_restart")
    /etc/init.d/apache restart
    ;;
  *)
    echo "Unknown command"
esac

Затем вы настраиваете authorized_keysфайл так:

command="/bin/sh /home/user/commands.sh" ssh-dss AAAAC8ghi9ldw== user@host

backupПользователь может запустить эти команды , как так:

# diskspace
$ ssh -q user@remote_host diskspace
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/dev-root   39G  2.2G   35G   6% /

# dirlist
$ ssh -q remote_host dirlist
commands.sh
dump.sql

Ссылки

• SSH Советы и хитрости
• Пять минут на еще более безопасный SSH

Ограниченная оболочка

Вам нужно назначить ограниченную оболочку, такую ​​как scponly или rssh.

Когда вы используете scp или sftp, вы подключаетесь к удаленному сайту через ssh, а затем удаленная оболочка выполняет процесс scp или sftp. Что вам нужно, так это ограниченная оболочка, которая позволяет только scp или sftp блокировать вход в систему.