Actualmente tengo algunos servicios diferentes ejecutándose en mi servidor doméstico y, para simplificar, tengo una única máquina virtual que administra los certificados a través de certbot y simplemente los copio a través de la red usando SCP.
Las conexiones ssh están protegidas con claves, pero como las estoy ejecutando de forma automática, las claves en sí no requieren una contraseña, lo que obviamente no es ideal.
Las claves solo se almacenan en la cuenta raíz de la máquina virtual que administra certbot, pero aún así me gustaría tener una opción en la que el script pueda copiar los archivos sin que yo tenga que tener esencialmente un método no seguro para el acceso raíz a otros sistemas en mi red si alguien obtuvo acceso a uno de ellos.
¿Hay alguna manera de permitir que solo ciertos comandos se pasen a través de una conexión ssh sin permitir que se abra una sesión de shell, o alguien puede pensar en otra forma de copiar los archivos en mi trabajo cron semanal que no dejaría una opción para ¿Alguien que pueda conectarse a mis otras máquinas?
Mi enrutador solo habilita al usuario para certbot un sábado por la noche, lo que permite que mi VM ingrese y ejecute un script que deshabilita la regla de firewall que bloquea el puerto 80, ejecuta el comando certbot renew, habilita las reglas de firewall nuevamente y deshabilita al usuario de certbot . Me siento bastante cómodo con esto ya que solo hay un período máximo de 15 minutos cada semana en el que el usuario del enrutador está habilitado.
El problema es la copia de los certificados ya que obviamente al realizarse como root las cuentas están activas en todo momento.
#!/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"
Respuesta1
Puede generar múltiples pares de claves ssh.
En el servidor remoto puedes usar las opciones avanzadas del authorized_keysarchivo y agregar límites a cada clave pública. Eso le permite agregar restricciones a la cantidad de inicios de sesión de acceso que se otorgan con un par de claves en particular.
Consulte la descripción del formato de archivo autorizado_keys enhttps://www.freebsd.org/cgi/man.cgi?sshd(8)para las opciones y su significado.
Las opciones útiles son, por ejemplo command=, las que limitan el acceso a un solo comando/ejecutable/script.
Bastante típico es forzar internal-sftp; entonces sólo se permitirán transferencias de archivos con sftp.
O from=que limiten la IP de origen desde la que se aceptan conexiones.
De manera similar, /etc/ssh/sshd_configpuede establecer requisitos adicionales para los inicios de sesión de root con una Matchdirectiva, es decir, cuando aún necesita permitir inicios de sesión con contraseña para todos los usuarios habituales, puede usar eso para configurar que solo se acepten inicios de sesión basados en claves públicas para 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
Y, por supuesto, puede evitar todo el problema de la cuenta raíz/privilegiada configurando un enfoque de extracción en lugar de inserción.