Linux ssh: consente l'autenticazione con chiave pubblica senza fornire diritti di lettura dell'utente alla chiave privata

Gli utenti che hanno effettuato l'accesso sul mio server Linux dovrebbero essere in grado di inviare a un computer remoto specifico un account predefinito. L'autenticazione sulla macchina remota utilizza la chiave pubblica, quindi sul server è disponibile la chiave privata corrispondente.

Non voglio che gli utenti del server siano effettivamente in grado di leggere la chiave privata. Fondamentalmente, il fatto che abbiano accesso al server consente loro il diritto ssh e rimuoverli dal server dovrebbe anche impedire la connessione al computer remoto.

Come posso consentire agli utenti di aprire una connessione ssh senza dare loro l'accesso in lettura alla chiave privata?

I miei pensieri finora: ovviamente l'eseguibile ssh deve essere in grado di leggere la chiave privata, quindi deve funzionare sotto un altro utente sul server che ha questi diritti. Una volta stabilita la connessione ssh, posso quindi "inoltrarla" all'utente in modo che possa immettere comandi e interagire con la macchina remota.

è un buon approccio?
Come devo implementare il forward?
In che modo l'utente può avviare la connessione (ovvero, l'esecuzione di ssh da parte dell'utente che ha i diritti di lettura sulla chiave)?
C'è una scappatoia di sicurezza? - se gli utenti possono eseguire un ssh come un altro utente, possono fare tutto ciò che un altro utente potrebbe (incluso leggere la chiave privata)?

— Philipp
fonte

Sembra essere un duplicato di stackoverflow.com/questions/9286622/protecting-ssh-keys

— wenzul

Configurare il server remoto per accettare connessioni con quella chiave solo dall'IP del server? In questo modo anche se rubano la chiave non possono fare nulla.

@ AndréDaniel, forse potrebbero accedere a un altro computer completamente non correlato, configurato anche per accettare accessi senza password dal server. Questa è l'unica ragione per cui mi viene in mente di avere una configurazione come questa; se non è così, sono piuttosto curioso di sapere cosa sia. (Non importa, davvero.)

— David Z,

@DavidZ Non capisco davvero ... la chiave non dovrebbe essere attendibile da nessuna parte ma sul server di destinazione supponendo che l'IP corrisponda a quello del primo server (a cui gli utenti si connettono).

Se è necessario bloccarlo in questo modo, suppongo che tu abbia adottato misure per impedire agli utenti di aggiungere nuove chiavi pubbliche al ~/.ssh/authorized_keysfile?

— mpontillo,

Risposte:

Questo è uno dei motivi sudoesiste. Consenti semplicemente agli utenti di eseguire 1 singolo comando con solo le opzioni della riga di comando pre-autorizzate e vengono risolte le più ovvie elusioni. per esempio

#/etc/sudoers
%users ALL = (some_uid) NOPASSWD: /usr/bin/ssh -i /home/some_uid/.ssh/remote-host.key username@remotehost

imposta in sudomodo che tutti i membri del gruppo userspossano eseguire il comando ssh come utente some_uid senza immettere la propria password (o quella dell'account some_uid) quando eseguono:

sudo -u some_uid /usr/bin/ssh -i /home/some_uid/.ssh/remote-host.key username@remotehost

Rimuovere l' NOPASSWD:opzione per forzare gli utenti a immettere le proprie password prima di accedere all'host remoto.
Possibilmente impostare uno script alias o wrapper come una comodità per i tuoi utenti perché sudoè piuttosto esigente sull'uso degli argomenti corretti.

— HBruijn
fonte

Funziona come un fascino. Questa dovrebbe anche essere la risposta raccomandata per il duplicato menzionato da Wenzul.

— Philipp,

Questo sembra un buon caso d'uso per l'autenticazione basata su host. Questo è un metodo di autenticazione in cui SSH non utilizza la chiave di un singolo utente sul computer locale (in questo caso, il server) per l'autenticazione; utilizza invece la chiave privata dell'host , quella memorizzata /etc/ssh/e che è leggibile solo da root.

Per configurarlo, dovrai creare un file chiamato .shostssul computer remoto, nella home directory dell'utente a cui vuoi che le persone accedano (non in ~/.ssh). Il file dovrebbe avere il contenuto

server-hostname +

dove si server-hostnametrova il nome del server ed +è un segno più letterale che funge da carattere jolly che significa "qualsiasi utente".

Dovrai anche assicurarti che la macchina remota possa verificare la chiave host del server, il che significa che la chiave host del server deve essere elencata in una /etc/ssh/ssh_known_hostso ~/.ssh/known_hostssulla macchina remota. In caso contrario, è possibile configurarlo accedendo al computer remoto ed eseguendolo

ssh-keyscan server-hostname >> /etc/ssh/ssh_known/hosts

Dopo aver impostato questi passaggi, puoi eliminare completamente la chiave privata sul server, se non ti serve per nient'altro. (E se lo fai, puoi sempre impostarlo come leggibile solo da rooto qualcosa del genere.)

Puoi anche fare facilmente cose come consentire o negare a determinati utenti l'accesso al computer remoto. Vedi le pagine man di sshe hosts.equivper i dettagli.

Un problema con questa configurazione è che gli utenti che accedono al computer remoto possono modificare .shosts. Non c'è niente che possano fare che consentirebbe loro di accedere al computer remoto come un altro utente, ma potrebbero interrompere l'accesso proprio o altrui al computer remoto. Se questo è un problema, potresti essere in grado di rendere .shostsscrivibile solo rooto qualcosa del genere - non sono sicuro che funzioni, ma potresti provarlo e vedere. (Altri metodi come quello con sudosono suscettibili allo stesso rischio, poiché un utente può sempre eliminare ~/.ssh/authorized_keys.)

— David Z
fonte

+1; Penso che questa opzione offra una buona flessibilità, nel caso in cui l'utente debba utilizzare funzionalità SSH diverse dal terminale, come port forwarding, copia protetta, ecc. Anche un client SSH alternativo dovrebbe funzionare. L' sudoopzione potrebbe essere migliore per un ambiente bloccato, però ...

— mpontillo