Limitare in modo sicuro l'accesso a un repository Debian privato


9

Stavo cercando un metodo per limitare l'accesso a un repository Debian privato ed essere in grado di autenticarlo in modo non interattivo (cioè usando uno script)

L'articolo più utile che ho trovato se effettivamente uno dal sito di amministrazione Debian ma il metodo sicuro usa ssh e chiavi pubbliche / private. Funziona benissimo ma la chiave pubblica di ogni host deve trovarsi all'interno del file remote autorizzato_keys per autenticarsi correttamente. Non dice nulla sulla fornitura di password a ssh: // ma suppongo che dovrebbe essere possibile.

Hai provato altre alternative (ad es. Ftps)?

Grazie in anticipo


Il problema che ho con l'articolo sopra è che non dà solo accesso al repository APT, ma fornisce l'accesso shell al mio computer repository APT. È un rischio inaccettabile.
BobDoolittle,

Risposte:


5

Se corri sempre apt-getmanualmente sui tuoi server (nessun apt-getcomando automatico lanciato da crons), allora potresti prendere in considerazione l'uso dell'inoltro dell'agente ssh . Questo evita di dover gestire una coppia di chiavi pubblica / privata per server che gestisci ed è probabilmente più sicura che lasciare le chiavi private su ogni server.

Configurazione iniziale : connettiti ai server che desideri gestire e aggiungi qualcosa del genere /etc/apt/sources.list(questo esempio presuppone che tu voglia che i tuoi server si connettano managerall'account):

    deb ssh://manager@my.repository.org/path other stuff
  • crea una coppia di chiavi private / pubbliche sul tuo computer, johndoead esempio con il tuo login (a condizione che il tuo computer funzioni su debian: in caso contrario, puoi farlo da un server debian dedicato alla gestione):

    ssh-keygen
    
  • assicurarsi che sia protetto da una frase chiave forte
  • copia la tua chiave pubblica sul server repository in /home/manager/.ssh/authorized_keys:

    ssh-copy-id manager@my.repository.org
    

Una volta per sessione di gestione

  • avvia l'agente ssh sul tuo computer digitando:

    eval `ssh-agent`
    
  • aggiungi la tua chiave all'agente (questo richiederà la tua passphrase):

    ssh-add
    

Gestire un server

  • connettersi al server che si desidera gestire utilizzando ssh -A( -Aattiva l'inoltro dell'agente):

    ssh -A some.server.org
    
  • passare a root (se si desidera utilizzare sudoè necessario configurare /etc/sudoersaltrimenti sudointerromperà l'inoltro dell'agente, leggere questo ):

    su
    
  • ora dovresti essere in grado di connetterti all'account gestore del repository utilizzando ssh senza digitare nuovamente la password, grazie all'inoltro dell'agente. Pertanto, apt-getdovrebbe funzionare bene:

    apt-get udate
    

Terminare la sessione di gestione

  • Una volta terminata la gestione dei server, rimuovere le chiavi dall'agente:

    ssh-add -D
    

vantaggi

  • Non è richiesta molta configurazione iniziale
  • È necessaria solo una chiave privata
  • La chiave privata è protetta da una passphrase avanzata
  • Se qualcuno ottiene l'accesso come root a uno dei server, non avrà accesso immediato al server repository.
    • Si noti che se l'hacker è paziente e qualificato, può attendere fino a quando non ci si connette al server tramite l'inoltro dell'agente e può dirottare il meccanismo di inoltro per ottenere l'accesso al server del repository.
    • Per evitare ciò, è possibile utilizzare ssh-askper accettare / rifiutare ogni tentativo di utilizzare la chiave.
    • In ogni caso, l'hacker non avrà accesso alla chiave privata stessa: sarà solo in grado di dirottare il meccanismo di inoltro per utilizzare la chiave e solo durante il tempo in cui si è connessi al server.

Grazie ancora MiniQuark. In realtà, gli aggiornamenti sono incustoditi, ma questo è un ottimo metodo che potrei applicare a scopo di test.
Humber,

Il piacere è tutto mio! :) Felice se aiuta.
MiniQuark,

4

Un modo per farlo è solo quello di consentire a un determinato set di IP di accedere al repository. Funziona molto bene con LAN e VPN.

Semplice ed efficiente


1
Grazie Antoine :). In realtà, il repository che ho ora è accessibile usando quel metodo (http su una connessione OpenVPN). Limito gli IP che appartengono alla VPN. Lo svantaggio qui è che ogni host deve essere collegato alla VPN per accedere al repository, con è un po 'fastidioso (gestire diversi certificati / chiavi). Ci scusiamo per non averlo specificato nella domanda.
Humber,

È vero, gestire OpenVPN è fastidioso, ma semplifica la gestione della sicurezza del repository. Inoltre, gli utenti non devono preoccuparsi delle credenziali una volta all'interno della VPN.
Antoine Benkemoun,

2

La soluzione ssh + chiavi pubbliche / private non è poi così male:

  • accedi come root sul computer client
  • digitare ssh-keygen, quindissh-copy-id your_login@your.repository.org
  • modifica /etc/apt/sources.liste aggiungi qualcosa come:

    deb ssh://your_login@your.repository.org/path other stuff
    

Concesso, richiede di inserire la chiave pubblica di ciascun server nel ~/.ssh/authorized_keysfile sul server, ma non è così complicato (vedi sopra) e ti dà il controllo su quali server consenti o meno in un dato momento (puoi rimuovere una chiave in in qualsiasi momento authorized_keys).


Grazie MiniQuark. Sì, questa soluzione non è poi così male, ma ssh-copy-id non funziona se l'autenticazione della password è disabilitata nel server openssh. Ho pensato di diffondere lo stesso file chiave su ciascun client utilizzando il repository per poterlo utilizzare. Per maggiore sicurezza, verrà utilizzato un utente con autorizzazioni minime. È quasi uguale alla condivisione delle credenziali. Attualmente sto testando questo metodo per verificare come si comporta / funziona.
Humber,


0

Il link nella tua domanda mostra più metodi. Vuoi il numero 2, https + autenticazione di base.


Grazie Giustino. Penso che il trasporto https con apt funzioni solo se è installato apt-transport-https. Questa è un'alternativa interessante. L'unico inconveniente sono le credenziali in sources.list
Humber,

chmod 600 /etc/apt/sources.list
Giustino,
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.