Come far funzionare insieme chiavi condivise .ssh / authorized_keys e sudo?


15

Ho installato .ssh / authorized_keys e sono in grado di accedere con il nuovo "utente" usando la chiave pub / privata ... Ho anche aggiunto "utente" all'elenco dei sudoers ... il problema che ho ora è quando Provo ad eseguire un comando sudo, qualcosa di semplice come:

$ sudo cd /root

mi chiederà la mia password, che inserisco, ma non funziona (sto usando la password della chiave privata che ho impostato)

Inoltre, ho disabilitato la password dell'utente tramite

$ passwd -l user

Cosa mi sto perdendo?

Da qualche parte le mie osservazioni iniziali sono state fraintese ...

Sto cercando di rafforzare il mio sistema ... l'obiettivo finale è quello di utilizzare le chiavi pub / private per fare il login rispetto alla semplice autenticazione con password. Ho capito come impostare tutto ciò tramite il file authorized_keys.

Inoltre alla fine prevarrò gli accessi al server tramite l'account di root. Ma prima di farlo ho bisogno di sudo per lavorare per un secondo utente (l'utente con il quale accederò al sistema in ogni momento).

Per questo secondo utente voglio impedire accessi con password regolari e forzare solo accessi a chiave pubblica / privata, se non blocco l'utente tramite "passwd -l user ... quindi se non uso una chiave, posso ancora entrare nel server con una password normale.

Ma, soprattutto, devo far funzionare sudo con una configurazione di chiave pub / privata con un utente a cui è stata disabilitata la password.


Modifica: OK, penso di averlo (la soluzione):

1) Ho modificato / etc / ssh / sshd_config e impostato PasswordAuthentication no Ciò impedirà gli accessi con password ssh (assicurarsi di avere una configurazione di chiave pubblica / privata funzionante prima di farlo

2) Ho modificato l'elenco dei sudoers visudoe aggiunto

root      ALL=(ALL) ALL
dimas     ALL=(ALL) NOPASSWD: ALL

3) root è l'unico account utente che avrà una password, sto testando con due account utente "dimas" e "sherry" che non hanno una password impostata (le password sono vuote passwd -d user)

Quanto sopra impedisce essenzialmente a tutti di accedere al sistema con password (è necessario impostare una chiave pubblica / privata).

Inoltre, gli utenti nell'elenco dei sudoer hanno capacità di amministrazione. Possono anche suaccount diversi. Quindi sostanzialmente "dimas" può sudo su sherry, tuttavia "dimas NON può farlo su sherry. Allo stesso modo qualsiasi utente NON nell'elenco dei sudoers NON può fare su usero sudo su user.

NOTA Quanto sopra funziona ma è considerato di scarsa sicurezza. Qualsiasi script in grado di accedere al codice come utente "dimas" o "sherry" sarà in grado di eseguire sudo per ottenere l'accesso root. Un bug in ssh che consente agli utenti remoti di accedere nonostante le impostazioni, un'esecuzione di codice remoto in qualcosa come Firefox o qualsiasi altro difetto che consente l'esecuzione di codice indesiderato poiché l'utente sarà ora in grado di eseguire come root. Sudo dovrebbe sempre richiedere una password o puoi anche accedere come root invece di qualche altro utente.

Risposte:


10

sshe sudonon hanno nulla a che fare l'uno con l'altro. L'impostazione di un sshmetodo di autenticazione non farà nulla per sudo. sudonon capirà una sshpassword.

passwd -lè destinato a bloccare l'account di un utente, in modo che non possa più autenticarsi tramite password. È praticamente l'opposto di quello che vuoi, che consente all'utente di autenticarsi senza password.

Penso che ciò che vuoi sia l' NOPASSWDopzione nel tuo sudoersfile .

(PS, non c'è motivo per eseguire un cdcomando sudo. cdNon si propaga ai processi padre, quindi non appena si sudoesce, si è tornati da dove si è iniziato.)

Modifica: continui a dire che vuoi bloccare la password dell'account e vuoi che sudo capisca le chiavi pubbliche / private. Siamo spiacenti, sudo non utilizzerà i tasti ssh. Non è ssh. Se non vuoi che gli utenti siano in grado di accedere con le loro password, penso che la risposta sia disabilitare l'autenticazione con password ssh , non bloccare l'account. Quindi è possibile conservare una password per gli utenti, che possono utilizzare per eseguire sudo dopo aver effettuato l'accesso tramite ssh authorized_keys.


ok, ma il fatto che l'utente non abbia password tramite: passwd -l user ... non fa funzionare il comando sudo?
farinspace,

@farinspace Sì, capisco meglio la domanda e ho sostanzialmente ampliato le mie osservazioni. passwd -lrimuove la password nel senso che l'account è BLOCCATO, ovvero nessuna password funzionerà. Si desidera disattivare l'autenticazione della password in sudo.
Coneslayer

come è questa logica: disattivare la password nel file sudoers sarebbe comunque sicuro, poiché il sistema è rafforzato tramite gli accessi chiave pub / chiave privata ... e ancora solo l'amministratore sarebbe in grado di aggiungere utenti all'elenco
sudoers

quando si usa una chiave privata è tipico impostare una password per essa, oppure è abbastanza sicuro da non averla impostata e bypassare qualsiasi immissione della password all'accesso al server
farinspace

4
@coneslayer questa risposta non è precisa al 100%. Come puoi vedere di seguito, sudo può essere configurato per rispettare l'autenticazione ssh.
Andre de Miranda,

18

Quello che vuoi fare è possibile ma richiederà un po 'di esperienza in quanto dovrai compilare un modulo PAM chiamato pam-ssh-agent-auth .

Il processo è ragionevolmente semplice:

$ sudo aptitude install libssl-dev libpam0g-dev build-essential checkinstall
$ wget "http://downloads.sourceforge.net/project/pamsshagentauth/pam_ssh_agent_auth/v0.9.3/pam_ssh_agent_auth-0.9.3.tar.bz2"
$ tar -xjvf pam_ssh_agent_auth-0.9.3.tar.bz2
$ cd pam_ssh_agent_auth-0.9.3

$ ./configure --libexecdir=/lib/security --with-mantype=man

$ make
$ sudo checkinstall

Modifica la configurazione sudo:

$ sudo visudo

Aggiungi quanto segue:

Defaults env_keep += SSH_AUTH_SOCK

Continua modificando le impostazioni sudo PAM:

$ sudo vi /etc/pam.d/sudo

Aggiungi (appena sopra le righe @include):

**auth [success=2 default=ignore] pam_ssh_agent_auth.so file=~/.ssh/authorized_keys**
@include common-auth
@include common-account


4
Questa dovrebbe essere la risposta accettata
Christopher Monsanto

1
Queste istruzioni (in particolare le /etc/pam.d/sudoistruzioni) non sono aggiornate per le versioni correnti di Ubuntu. Ho fornito istruzioni aggiornate nella mia risposta.
Chris Pick,

4

La risposta di Andre de Miranda fornisce una buona soluzione usando pam_ssh_agent_auth , ma le parti non sono aggiornate. In particolare le /etc/pam.d/sudoistruzioni quando si utilizzano molte versioni correnti di Linux.

Se stai eseguendo Ubuntu 12.04 con precisione, ho effettivamente semplificato il processo fornendo un pam_ssh_agent_auth compilato da un ppa: ppa: cpick / pam-ssh-agent-auth .

È possibile installare il pacchetto eseguendo:

sudo add-apt-repository ppa:cpick/pam-ssh-agent-auth
sudo apt-get install pam-ssh-agent-auth

Dopo l'installazione, se desideri utilizzare questo modulo PAM con sudo dovrai configurare le impostazioni di sudo e la configurazione PAM, in Ubuntu 12.04 preciso puoi farlo creando i seguenti due file:

/etc/sudoers.d/pam-ssh-agent-auth:

Defaults    env_keep+="SSH_AUTH_SOCK"

/etc/pam.d/sudo:

ent#%PAM-1.0

auth       required   pam_env.so readenv=1 user_readenv=0
auth       required   pam_env.so readenv=1 envfile=/etc/default/locale user_readenv=0
auth       sufficient pam_ssh_agent_auth.so file=/etc/security/authorized_keys
@include common-auth
@include common-account
@include common-session-noninteractive

Se stai usando lo chef, il processo di cui sopra può essere automatizzato con il mio libro di cucina, disponibile in una delle due seguenti posizioni:
https://github.com/cpick/pam-ssh-agent-auth
http: //community.opscode .com / libri di cucina / pam-ssh-agent-auth .

La filesdirectory del ricettario contiene i file /etc/pam.d/sudoe /etc/sudoers.d/pam-ssh-agent-authsopra descritti che funzionano con Ubuntu 12.04 preciso e dovrebbero essere un utile punto di partenza quando si usano altre versioni / distribuzioni.


-1

L'unico modo che conosco per bypassare l'inserimento di una password è disabilitandola nel tuo sudoersfile.

Qualcosa del genere darà a roottutti i membri di wheel pieno accesso senza password:

root    ALL=(ALL)   NOPASSWD: ALL
%wheel  ALL=(ALL)   NOPASSWD: ALL

Questo non è assolutamente consigliato , tuttavia. Se hai un comando specifico da eseguire per questo server, dai loro l'accesso solo a quel comando. O meglio ancora, trova un modo diverso di realizzare ciò che vuoi fare che non richiede di perforare una falla di sicurezza.


non mi dispiace usare la password, il problema sembra essere dopo aver disabilitato la password dell'utente tramite: passwd -l user ... Posso ancora accedere al sistema tramite la chiave pub / privata (la chiave privata ha una password sicura) , quando faccio un sudo mi chiede una password ma questa non è la password della chiave privata, sembra, dove è impostata questa password se la disabilito per l'utente (preferirei cercare di evitare di mantenere una password sul sistema e sulla chiave privata)
farinspace il

"dove viene impostata questa password se ive la disabilita per l'utente?" Da nessuna parte. Non è possibile inserire alcuna password che funzionerà perché hai bloccato l'account.
Coneslayer

Dovresti riattivare l'account sul sistema remoto e quindi impostare la password. Ad ogni modo, dovresti sicuramente mantenere la password su entrambe le macchine. Se non altro per motivi diversi dagli accessi locali in caso di guasto.
Jack M.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.