Tengo alrededor de 30 servidores CentOS 6 casi idénticos que necesito para poder enviar archivos de configuración actualizados automáticamente usando una clave rsa para iniciar sesión como root. Por lo general, esto será solo rsync, pero a veces es posible que deba ejecutar comandos en los servidores, por lo que también necesita ssh. Dado que esto se ejecutará como un script para actualizar los 30 servidores, no quiero tener una frase de contraseña en la clave.
Tengo esa parte funcionando bien. Creé la clave rsa, la agregué a Authorized_keys para root, para poder ssh o rsync con los servidores sin necesidad de escribir una contraseña.
He configurado Authorized_keys para aceptar solo la clave de un único nombre de host, lo que debería hacer que esta configuración sea relativamente segura. Sin embargo, todavía no me siento totalmente cómodo con él, por lo que me gustaría configurarlo para que envíe un correo electrónico a nuestro buzón tecnológico compartido cada vez que se use esta clave.
Muchas veces iniciaré sesión en estos servidores como yo mismo y demandaré para obtener root. Esto está bien y no quiero enviar spam al buzón técnico cada vez que uno de nosotros inicia sesión. Solo quiero recibir los correos electrónicos cuando se usa la clave SSH.
Esto es lo que tengo hasta ahora, en el servidor 1 [hasta 30].example.com:
cat /root/.ssh/authorized_keys
from="pusher.example.com",environment="SSHKEY=1" ssh-rsa AAAAB3NzaIwAAAxetcetc== root@pusher
tail -n 3 /root/.bash_profile
if [[ "${SSHKEY}" == "1" ]] ; then
echo 'Either we are getting hacked, or somebody used the SSH key on pusher to push something out to ' `hostname` ' at ' `date` | mail -s "WARNING - ROOT SSH KEY USED ON `hostname`!" [email protected]
fi
Esto funciona perfectamente para SSH: si ingreso como yo mismo y ejecuto su para obtener root, no recibo el correo electrónico, pero si inicio sesión en Pusher y ejecuto:
ssh -i /root/.ssh/server1.pri server1.example.com
Recibo un correo electrónico. El problema es enviar archivos. Si ejecuto cualquiera de:
scp -i /root/.ssh/server1.pri /tmp/file.txt server1.example.com:/tmp/
rsync -e 'ssh -i /root/.ssh/server1.pri' /tmp/test.txt server1.example.com:/tmp/
Todavía no recibo el correo electrónico.
¿Hay alguna manera, en lugar de depender de bash_profile, de configurar esto para enviar un correo electrónico cada vez que se use la clave, para cualquier cosa? (O alternativamente, ¿solo si se usa para scp o rsync, y restringiré la clave para ejecutarlos solo?)
Respuesta1
puedes hacer mal uso /root/.ssh/rcpara su propósito (ver man sshd) e incluya un mailxcomando allí.
Respuesta2
~/.bash_profile se utiliza si se invoca bash como un shell de inicio de sesión interactivo. ~/.bashrc se utiliza para shells sin inicio de sesión. Sin embargo, usar ese archivo no es confiable, porque el atacante podría requerir que los archivos de inicialización del shell no se lean en absoluto.
Respuesta3
Desde la página de manual de sshd, sección 'claves_autorizadas':
comando = "comando"
Especifica que el comando se ejecuta siempre que se utilice esta clave para la autenticación. Se ignora el comando proporcionado por el usuario (si lo hay). El comando se ejecuta en un pty si el cliente lo solicita; de lo contrario, se ejecuta sin tty. Si se requiere un canal limpio de 8 bits, no se debe solicitar un pty o se debe especificar no-pty. Se puede incluir una cita en el comando entrecomitándola con una barra invertida. Esta opción puede resultar útil para restringir ciertas claves públicas para realizar solo una operación específica. Un ejemplo podría ser una clave que permita realizar copias de seguridad remotas pero nada más. Tenga en cuenta que el cliente puede especificar el reenvío TCP y/o X11 a menos que estén explícitamente prohibidos. El comando proporcionado originalmente por el cliente está disponible en la variable de entorno SSH_ORIGINAL_COMMAND. Tenga en cuenta que esta opción se aplica a la ejecución de shell, comando o subsistema. También tenga en cuenta que este comando puede ser reemplazado por una directiva ForceCommand sshd_config(5) o un comando integrado en un certificado.
Podrías agregar esa opción a tu clave, tal como agregaste las opciones 'de' y 'entorno':
cat /root/.ssh/authorized_keys
from="pusher.example.com",environment="SSHKEY=1" ssh-rsa AAAAB3NzaIwAAAxetcetc== root@pusher