Le funzionalità di registrazione SSH sono equivalenti alla registrazione su per l'autenticazione con chiave pubblica / privata?

Qui al lavoro, abbiamo un account di accesso condiviso non root su UNIX che viene utilizzato per amministrare una particolare applicazione. La politica è di non consentire accessi diretti all'account condiviso; devi accedere come te stesso e utilizzare il comando "su" per passare all'account condiviso. Questo è per scopi di registrazione / sicurezza.

Ho iniziato a utilizzare l'autenticazione della chiave pubblica / privata SSH con un agente per consentirmi di inserire la mia password una volta al giorno e consentire all'inoltro dell'agente di eliminare le richieste di password per il resto della giornata. È veramente carino.

Tuttavia, alcuni sistemi sono bloccati, quindi devo usare il comando "su" per accedere all'account condiviso. Arg! Torna a inserire password per tutto il tempo!

Esistono abbastanza informazioni registrate con l'autenticazione della chiave pubblica / privata SSH in modo tale che potrei avere una ragionevole possibilità di richiedere una modifica della politica per consentire l'accesso remoto a un account condiviso se vengono utilizzate chiavi pubbliche / private?

Ho avuto uno sguardo da amministratore in / var / log / secure e dice solo che una chiave pubblica è stata accettata per un account utente da un determinato indirizzo IP. Non diceva chi fosse la chiave pubblica o chi fosse la chiave privata per l'autenticazione.

Esistono molti livelli di registrazione disponibili attraverso il sshd_configfile. Vedi la pagina man e cercala LogLevel. Il livello predefinito è INFOma è banalmente facile aumentarlo fino a VERBOSEuno dei DEBUG#livelli.

Inoltre, dovresti esplorare sudocome alternativa a su. Una discussione completa dei benefici sudosarebbe una questione a sé stante. Ma posso dire che con sudote puoi personalizzare la frequenza con cui devi inserire la password, quali comandi possono essere eseguiti, ecc., Tutti controllabili attraverso il file di configurazione sudoers .

Un altro modo sarebbe spostarsi authorized_keysal di fuori dell'ambito dell'utente (ad esempio, /etc/ssh/authorized_keys) in modo tale che solo gli amministratori di sistema possano controllare quali chiavi pubbliche possono essere utilizzate per accedere a determinati account.

Abbiamo usato per modificare la AuthorizedKeysFiledirettiva in sshd_configqualcosa di simile al seguente.

AuthorizedKeysFile /etc/ssh/authorized_keys/%u

Quindi crea e popola la /etc/ssh/authorized_keysdirectory con i file per ciascun utente che dovrebbe essere in grado di accedere, assicurandoti che il rootfile sia leggibile / scrivibile solo per il root e altri file leggibili da un utente appropriato, come questo:

-rw-------  1 root root    1,7K 2008-05-14 14:38 root
-rw-r-----  1 root john     224 2008-11-18 13:15 john

Ogni file contiene una serie di chiavi pubbliche che potranno accedere a un determinato account. È abbastanza comune per ogni account utente che esiste anche un rispettivo gruppo.

L'uso di chiavi pubbliche / private è un metodo molto migliore per controllare l'accesso degli utenti remoti. Non è necessario modificare la password ogni mese (non è nemmeno necessario impostarla) e non è necessario modificarla solo perché un dipendente ha lasciato la propria azienda semplicemente rimuovendo la propria chiave pubblica; e, naturalmente, con le opzioni SSH ( http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8#SSHRC) è possibile definire con precisione cosa e da dove un determinato utente potrebbe avere accesso.

L'autenticazione della chiave pubblica / privata SSH è separata dall'autenticazione dell'host. Sei sfortunato qui. È possibile richiedere tuttavia che i membri di un determinato gruppo possano eseguire determinati comandi amministrativi sudosenza password, come nell'esempio seguente consente agli utenti del secretariesgruppo di gestire gli account:

# file: /etc/sudoers
...
%secretaries    ALL= NOPASSWD: /usr/bin/adduser, /usr/bin/rmuser   
...