Безопасный метод автоматического копирования файлов через корневое ssh-соединение

Безопасный метод автоматического копирования файлов через корневое ssh-соединение

В настоящее время на моем домашнем сервере запущено несколько различных служб, и для простоты у меня есть одна виртуальная машина, которая управляет сертификатами через certbot и просто копирует их по сети с помощью SCP.

SSH-соединения защищены ключами, но поскольку я использую их в автоматическом режиме, сами ключи не требуют пароля, что, очевидно, не идеально.

Ключи хранятся только в учетной записи root виртуальной машины, которая управляет certbot, но мне все равно хотелось бы иметь возможность, при которой скрипт мог бы копировать файлы, не прибегая к незащищенному методу доступа root к другим системам в моей сети, если кто-то получит доступ к одной из них.

Есть ли способ разрешить передачу только определенных команд через SSH-соединение, не позволяя открывать сеанс оболочки, или может кто-нибудь придумать другой способ копирования файлов в моем еженедельном задании cron, который не оставил бы возможности кому-либо передавать данные по SSH на другие мои машины?

Мой маршрутизатор включает пользователя для certbot только в субботу вечером, что позволяет моей виртуальной машине подключаться по ssh и запускать скрипт, который отключает правило брандмауэра, блокирующее порт 80, запускает команду certbot renew, снова включает правила брандмауэра и отключает пользователя certbot. Мне это достаточно удобно, так как есть только максимальное 15-минутное окно каждую неделю, когда пользователь маршрутизатора включен.

Проблема заключается в копировании сертификатов, поскольку, очевидно, оно выполняется с правами root, а учетные записи постоянно активны.

#!/bin/bash
ssh [email protected] "/system script run certbotenable"
#ufw allow 80
certbot renew
#ufw delete allow 80
systemctl restart apache2
ssh [email protected] "/system script run certbotdisable"
scp /etc/letsencrypt/live/sazed.mydomain.com/cert.pem root@sazed:/etc/pve/local/pveproxy-ssl.pem
scp /etc/letsencrypt/live/sazed.mydomain.com/privkey.pem root@sazed:/etc/pve/local/pveproxy-ssl.key
scp /etc/letsencrypt/live/rashek.mydomain.com/cert.pem root@rashek:/root/ssl/fullchain.pem
scp /etc/letsencrypt/live/rashek.mydomain.com/privkey.pem root@rashek:/root/ssl//privkey.key
ssh root@sazed "service pveproxy restart"

решение1

Вы можете сгенерировать несколько пар ключей SSH.

На удаленном сервере вы можете использовать расширенные параметры в authorized_keysфайле и добавлять ограничения для каждого открытого ключа. Это позволяет вам добавлять ограничения на количество разрешенных входов в систему с определенной парой ключей.

См. описание формата файла authorized_keys вhttps://www.freebsd.org/cgi/man.cgi?sshd(8)для опций и их значения.

Полезными опциями являются, например, command=те, которые ограничивают доступ только к одной команде/исполняемому файлу/скрипту.

Довольно типичным является принудительное использование internal-sftp; тогда будет разрешена только передача файлов с помощью sftp.

Или from=ограничить исходный IP-адрес, с которого принимаются соединения

Аналогично /etc/ssh/sshd_configвы можете установить дополнительные требования для входа root с помощью Matchдирективы, то есть, когда вам все еще нужно разрешить вход по паролю для всех обычных пользователей, вы можете использовать ее, чтобы указать, что для root принимаются только входы на основе открытого ключа.

# /etc/ssh/sshd_config
#here go defaults for all connections/users
PasswordAuthentication yes
PubkeyAuthentication yes
...
# Use Match directives to override default settings and specify specific settings
# for users, groups, hosts 
# https://man.openbsd.org/sshd_config#Match
Match User root
    PasswordAuthentication no
   

И, конечно, вы можете избежать всей этой проблемы с учетной записью root/privilege, настроив подход pull, а не push.

Связанный контент