Envie um email sempre que uma chave SSH for usada

Question

Eu tenho cerca de 30 servidores CentOS 6 quase idênticos que eu preciso ser capaz de enviar arquivos de configuração atualizados automaticamente usando uma chave rsa para logar como root. Normalmente, isso será apenas rsync, mas às vezes pode ser necessário executar comandos nos servidores, portanto, ele também precisa do ssh. Como isso será executado como um script para atualizar todos os 30 servidores, não quero ter uma frase secreta na chave.

Eu tenho essa parte funcionando bem. Eu criei a chave rsa, adicionei a authorized_keys para root, então eu posso ssh ou rsync para os servidores sem precisar digitar uma senha.

Eu tenho o authorized_keys configurado para aceitar apenas a chave de um único nome de host, o que deve tornar essa configuração relativamente segura. No entanto, eu ainda não estou totalmente confortável com isso, então gostaria de configurá-lo para enviar um e-mail para nossa caixa de correio de tecnologia compartilhada toda vez que essa chave for usada.

Há muitas vezes que eu vou entrar nesses servidores como eu mesmo, e su'ing para me dar root. Isso é bom, e não quer spam na caixa de correio de tecnologia toda vez que um de nós faz o login. Eu só quero receber os emails quando a chave SSH é usada.

Aqui está o que eu tenho até agora, no server1 [até 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

Isso funciona perfeitamente para o SSH - Se eu colocar o putty como eu e executar o su para obter o root, não recebo o email, mas se eu fizer login no pusher e executar:

ssh -i /root/.ssh/server1.pri server1.example.com

Eu recebo um email. O problema é empurrar arquivos. Se eu executar um dos seguintes:

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/

Ainda não recebo o email.

Existe uma maneira, em vez de depender do bash_profile, para configurar isso para enviar um email sempre que a chave for usada? (Ou, alternativamente, apenas se for usado para scp ou rsync, e eu vou restringir a chave para apenas executá-los?)

    

Answer 1

Você pode usar indevidamente /root/.ssh/rc para o seu propósito (veja man sshd) e incluir um comando mailx lá.

    

Answer 2

Na página do manual do sshd, seção 'authorized_keys':

command="command"

Specifies that the command is executed whenever this key is used for authentication. The command supplied by the user (if any) is ignored. The command is run on a pty if the client requests a pty; otherwise it is run without a tty. If an 8-bit clean channel is required, one must not request a pty or should specify no-pty. A quote may be included in the command by quoting it with a backslash. This option might be useful to restrict certain public keys to perform just a specific operation. An example might be a key that permits remote backups but nothing else. Note that the client may specify TCP and/or X11 forwarding unless they are explicitly prohibited. The command originally supplied by the client is available in the SSH_ORIGINAL_COMMAND environment variable. Note that this option applies to shell, com‐ mand or subsystem execution. Also note that this command may be superseded by either a sshd_config(5) ForceCommand directive or a command embedded in a certificate.

Você pode adicionar essa opção à sua chave, assim como adicionou as opções 'de' e 'ambiente':

cat /root/.ssh/authorized_keys
from="pusher.example.com",environment="SSHKEY=1" ssh-rsa AAAAB3NzaIwAAAxetcetc== root@pusher

    

Answer 3

~ / .bash_profile é usado, caso o bash seja invocado como um shell de login interativo. ~ / .bashrc é usado para shells não-login. No entanto, usar esse arquivo não é confiável, porque o invasor pode exigir que os arquivos de inicialização do shell não sejam lidos.