risco de usar chaves públicas ssh

Eu tenho o servidor A e o servidor B (backup) e fiquei pensando, se alguém invadir o servidor A, isso pode ser potencialmente perigoso para invadir o servidor B se eu tiver configurado o login sem senha usando chaves públicas ssh?

Estou tentando configurar o rsnapshot.

obrigado

Sim, este é um dos problemas com as chaves SSH sem senha. Se você armazenar uma chave privada no servidor A que permita a conexão com o servidor B, obter acesso ao servidor A estará efetivamente obtendo acesso ao servidor B. (O contrário não é verdadeiro - obter acesso ao servidor B não resultaria em uma comprometimento imediato do servidor A, supondo que você também não tenha as chaves SSH configuradas para permitir logins sem senha nessa direção.

Existem algumas coisas que você pode fazer para atenuar isso:

• Se o processo não precisar ser totalmente automatizado, adicione uma senha às suas chaves SSH. (Isso provavelmente não funcionará para você, pois você nota que é para backup)
• Para logins sem senha em sua própria conta em várias máquinas, recomendo criar uma chave com senha para cada máquina em que você digita fisicamente e use um agente SSH para armazenar a chave na memória enquanto você a usa. O encaminhamento de agente deve permitir que você "salte" de host em host sem criar chaves em cada host remoto.
• Para chaves SSH automatizadas e sem senha, recomendo restringir os comandos que a chave pode executar. No seu authorized_keysarquivo, prefixe cada chave com:
  command="<allowed command line here>",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

Há 8 ou 9 anos, trabalhei em um ambiente de usuário compartilhado com centenas de usuários locais, e os logons baseados em chave SSH foram desativados porque não havia como impor políticas de senha nas chaves. Enquanto você estiver controlando o cenário completamente, hoje em dia as chaves SSH são definitivamente melhores do que apenas usar senhas.

Sim, a maioria dos guias na Internet impede que o ssh sem senha funcione, em vez de fazê-lo funcionar com segurança. Este guia mostra bem o que pode ser feito para reduzir os riscos. Basicamente (para citar o artigo):

• crie uma conta de função de propósito único para o trabalho: ou seja, um usuário dnssyncem cada máquina
• se possível, torne os arquivos graváveis ​​por esse usuário, em vez de depender de root
• para os bits que realmente precisam de acesso privilegiado, crie um script para fazer isso e use o sudo
• use command=e from=opções nos authorized_keysarquivos para restringir as chaves sem senha
• para fazer a transferência de arquivos, escreva um script para fazê-lo usando o rsync, na máquina receptora , para que o acesso remoto possa ser somente leitura
• se isso significa que o acesso à máquina inicial é necessário a partir da máquina remota, use em ssh-agentvez de criar uma segunda chave sem senha

Existem alguns problemas com as chaves ssh:

Nenhuma maneira centralizada de revogar uma chave.

Não há como impor políticas de senha às chaves (sua chave privada é criptografada e, em caso afirmativo, é criptografada com uma boa senha?).

Estes são os problemas que o kerberos resolve. No entanto, ele apresenta outros, ou seja, é mais complexo de implementar e requer uma infraestrutura de gerenciamento de usuários real para implantar e gerenciar.

De qualquer forma, embora as chaves autorizadas ssh permitam ataques do tipo morris-worm , ainda é melhor que os serviços .r e o telnet por milhas (anos-luz)

Em qualquer ambiente que eu tenha controle, sempre fui um defensor real do privilégio mínimo possível para as contas de serviço.

Nesse caso, sugiro garantir que a conta de usuário no servidor remoto tenha permissão para executar apenas um pequeno conjunto de executáveis ​​bem definido. Você pode usar várias contas no lado remoto e sudo para fazer isso.

Mesmo nesse caso, você ainda está sujeito aos erros de escalação de privilégios locais; portanto, seja meticuloso e acompanhe os erros de segurança.