rischio di utilizzo di chiavi pubbliche ssh

Ho il server A e il server B (backup) e mi chiedevo, se qualcuno si rompe nel server A, potrebbe essere potenzialmente pericoloso entrare nel server B se ho configurato l'accesso senza password usando le chiavi pubbliche ssh?

Sto provando a configurare rsnapshot.

Grazie

Sì, questo è uno dei problemi con le chiavi SSH senza password. Se si memorizza una chiave privata sul server A che consente di connettersi al server B, ottenere l'accesso al server A sta effettivamente ottenendo l'accesso al server B. (Non è vero il contrario: l'accesso al server B non comporterebbe un compromesso immediato del server A, presupponendo che non siano state impostate chiavi SSH per consentire accessi senza password in quella direzione.

Ci sono alcune cose che puoi fare per mitigare questo:

• Se non è necessario che il processo sia completamente automatizzato, aggiungere una password alle chiavi SSH. (Questo probabilmente non funzionerà per te, poiché noti che è per un backup)
• Per accessi senza password con il tuo account su più macchine, ti consiglio di creare una chiave con password per ogni macchina su cui digiti fisicamente e di utilizzare un agente SSH per archiviare la chiave in memoria mentre la usi. L'inoltro dell'agente dovrebbe consentire di "saltare" da un host all'altro senza creare chiavi su ciascun host remoto.
• Per le chiavi SSH automatizzate e senza password, consiglio di limitare i comandi che la chiave può eseguire. Nel tuo authorized_keysfile, aggiungi il prefisso a ciascuna chiave con:
  command="<allowed command line here>",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

8-9 anni fa ho lavorato in un ambiente utente condiviso con centinaia di utenti locali e gli accessi basati su chiavi SSH sono stati disabilitati perché non c'era modo di applicare criteri password sulle chiavi. Finché controlli completamente lo scenario, al giorno d'oggi le chiavi SSH sono decisamente migliori del semplice utilizzo di password.

Sì, la maggior parte delle guide su Internet smette di far funzionare ssh senza password, piuttosto che farlo funzionare in sicurezza. Questa guida fa un buon lavoro nel mostrare cosa si può fare per ridurre i rischi. Fondamentalmente (per citare l'articolo):

• creare un account con ruolo unico per il lavoro: ovvero un utente dnssyncsu ogni macchina
• se possibile, rendere i file scrivibili da quell'utente, piuttosto che fare affidamento sul fatto di essere root
• per quei bit che hanno davvero bisogno di un accesso privilegiato, crea uno script per farlo e usa sudo
• uso command=e from=opzioni nei authorized_keysfile per limitare le chiavi senza passphrase
• per eseguire il trasferimento di file, scrivere uno script per farlo utilizzando rsync, sulla macchina ricevente , in modo che l'accesso remoto possa essere di sola lettura
• se ciò significa che è necessario l'accesso alla macchina di avvio dalla macchina remota, utilizzare ssh-agentanziché creare una seconda chiave senza passphrase

Ci sono un paio di problemi con i tasti ssh:

Nessun modo centralizzato per revocare una chiave.

Non è possibile applicare criteri di password sulle chiavi (la tua chiave privata è crittografata e, in tal caso, è crittografata con una buona password?).

Questi sono i problemi che Kerberos risolve. Ne introduce altri, tuttavia, in particolare è più complesso da implementare e richiede una vera e propria infrastruttura di gestione degli utenti per la distribuzione e la gestione.

In ogni caso, sebbene ssh authorized_keys consenta attacchi di tipo morris-worm , è comunque meglio dei servizi .r e di telnet di miglia (anni luce)

In qualsiasi ambiente di cui ho avuto il controllo, sono sempre stato un vero sostenitore del privilegio minimo possibile per gli account di servizio.

In questo caso, suggerirei di garantire che l'account utente sul server remoto sia autorizzato a eseguire solo un piccolo set di file eseguibili. È possibile utilizzare più account sul lato remoto e sudo per ottenere questo risultato.

Anche in questo caso, sei ancora soggetto ai bug di escalation di privilegi locali, quindi sii meticoloso e tieni traccia dei bug di sicurezza strettamente.