Linux: configurato per l'amministratore remoto


51

Ogni tanto ricevo la strana richiesta di fornire supporto remoto, risoluzione dei problemi e / o ottimizzazione delle prestazioni su sistemi Linux.

Le aziende più grandi spesso dispongono già di procedure ben definite per fornire accesso remoto a venditori / fornitori e devo solo attenermi a queste. (Nel bene e nel male.)

D'altra parte, piccole aziende e individui si rivolgono invariabilmente a me per istruirli su ciò che devono fare per installarmi. In genere i loro server sono direttamente collegati a Internet e le misure di sicurezza esistenti consistono nelle impostazioni predefinite per qualunque sia la loro distribuzione Linux.

Quasi sempre avrò bisogno dell'accesso a livello di root e chiunque configurerà l'accesso per me non è un amministratore di sistema esperto. Non voglio la loro password di root e sono anche abbastanza sicuro che le mie azioni non saranno dannose, ma quali istruzioni ragionevolmente semplici dovrei dare a:

  • creare un account e scambiare credenziali in modo sicuro
  • imposta l'accesso root (sudo)
  • limitare l'accesso al mio account
  • fornire audit trail

(E sì, sono consapevole e avverto sempre quei clienti che una volta che ho accesso come amministratore per nascondere eventuali azioni dannose è banale, ma supponiamo che non ho nulla da nascondere e partecipare attivamente alla creazione di una pista di controllo.)

Cosa può essere migliorato con i passaggi seguenti?


Il mio set di istruzioni corrente:

creare un account e scambiare credenziali in modo sicuro

Fornisco un hash di password e chiedo che il mio account sia configurato con quella password crittografata, quindi non avremo bisogno di trasmettere una password di testo chiaro, sarò l'unico a conoscere la password e non inizieremo con una password debole prevedibile.

sudo useradd -p '$1$********' hbruijn

Fornisco una chiave pubblica SSH (specifica coppia di chiavi per client) e chiedo che abbiano impostato il mio account con quella chiave:

sudo su - hbruijn
mkdir -p ~/.ssh
chmod 0700 ~/.ssh
echo 'from="10.80.0.0/14,192.168.1.2" ssh-rsa AAAAB3NzaC1y***...***== hbruijn@serverfault' >> ~/.ssh/authorized_keys
chmod 0600 ~/.ssh/authorized_keys 

imposta l'accesso root (sudo)

Chiedo al cliente di impostare sudo per me con sudo sudoedito usando il loro editor preferito e aggiungo a /etc/sudoers:

hbruijn ALL=(ALL) ALL

limitare l'accesso al mio account

In genere il client consente ancora accessi basati su password e chiedo loro di aggiungere le seguenti due righe per /etc/ssh/sshd_configlimitare almeno il mio account solo alle chiavi SSH:

Match user hbruijn
PasswordAuthentication no

A seconda del client instraderò tutto il mio accesso SSH attraverso un singolo host bastion per fornire sempre un singolo indirizzo IP statico (ad esempio 192.168.1.2) e / o fornire l'intervallo di indirizzi IP utilizzato dal mio ISP (ad esempio 10.80. 0.0 / 14). Il client potrebbe dover aggiungere quelli a una whitelist del firewall se l'accesso a SSH è limitato (il più delle volte ssh non è filtrato).

Hai già visto quegli indirizzi IP come la from=restrizione nel ~.ssh/authorized_keysfile che limita gli host da cui la mia chiave può essere usata per accedere ai loro sistemi.

fornire audit trail

Fino ad ora nessun cliente me lo ha chiesto e non ho fatto nulla di specifico oltre a quello che segue per coprirmi il culo:

Cerco di utilizzare coerentemente sudocon i singoli comandi e provo a impedire l'uso di sudo -io sudo su -. Provo a non usare, sudo vim /path/to/file ma uso sudoeditinvece.

Per impostazione predefinita, tutte le azioni privilegiate verranno quindi registrate su syslog (e /var/log/secure):

Sep 26 11:00:03 hostname sudo:  hbruijn : TTY=pts/0 ; PWD=/home/hbruijn ; USER=jboss ; COMMAND=sudoedit /usr/share/jbossas/domain/configuration/domain.xml  
Sep 26 11:00:34 hostname sudo:  hbruijn : TTY=pts/0 ; PWD=/home/hbruijn ; USER=root ; COMMAND=/usr/bin/tail -n 5 /var/log/messages

Mi arrendo principalmente alla personalizzazione dei miei ambienti di lavoro, l'unica cosa che faccio veramente è impostare quanto segue nel mio ~/.bash_profileaumentare la storia di bash e includere i timestamp:

export HISTSIZE=99999999999
export HISTFILESIZE=99999999999
export HISTIGNORE="w:ls:ls -lart:dmesg:history:fg"
export HISTTIMEFORMAT='%F %H:%M:%S  '
shopt -s histappend

8
Puoi accedere (facile da modificare dopo il fatto) e persino condividere sessioni screen, quindi in casi estremi, il tuo cliente può vedere dal vivo quello che stai facendo.
Sven

Se si desidera aggiungere una pista di controllo migliore, è necessario istruirli ad abilitare la registrazione remota se ne hanno la possibilità
Fredi

Risposte:


24

L'unica cosa che viene in mente sarebbe quella di aggiungere --expiredatealla adduserchiamata.
Con ciò il cliente sa che il tuo accesso scadrà automaticamente a una data fissa.

Deve ancora fidarsi di te poiché hai l'accesso root e puoi ancora rimuovere il flag di scadenza.


15

È possibile registrare le sessioni con l' utilità script (1) .

$ script session.log
Script started, file is session.log
$ ls
file1  session.log
exit
Script done, file is session.log

allora tutto è in session.log.


Consiglieresti di eseguirlo sul tuo host, prima di avviare la sessione ssh su un sistema remoto, o includerlo come parte del mio profilo sul sistema remoto?
HBruijn,

1
Suppongo che potresti fare entrambe le cose: l'ho usato solo una volta che alla maggior parte delle persone non importa davvero.
user9517 supporta GoFundMonica il

7

Dato che stai già effettuando il login con una chiave pubblica SSH, le cose si restringerebbero un po 'se non fornissi un hash password; invece di dire loro di usare adduser --disabled-password(equivalentemente, useradd -p '!'penso), che è effettivamente equivalente a PasswordAuthentication noquell'account, inoltre non c'è alcuna possibilità che qualcuno ficcanaso nella tua e-mail possa forzare bruscamente l'hash della password e accedere come te.


3
L'aggiunta di Match user hbruijn \n PasswordAuthentication noa sshd_config dovrebbe impedire a chiunque di accedere in remoto con la mia password decrittata (potenzialmente gli utenti locali potrebbero usarla con su - hbruijn) ma per quanto ne so devo comunque avere una password valida per sudoscopi. Forse dovrei semplicemente reimpostare la mia password dopo aver effettuato l'accesso?
HBruijn,

Oh, buon punto su sudo. Non sono sicuro se a un account in --disabled-passwordstato possa essere assegnata una password eseguendo passwdda quell'account.
zwol,

Inoltre, cosa impedisce a chiunque di ascoltare l'hash della password fornito? Quella parte è un collegamento debole che mina usando le chiavi ssh dove non importa se la tua chiave pubblica viene intercettata.
JamesRyan,

3
Quel link debole potrebbe essere risolto facendo in modo che il client aggiunga anche una riga nel file sudoers come hbruijn ALL=(ALL) NOPASSWD: /usr/bin/passwd hbruijn?
Dezza,

2

Perché fornire una password a tutti, quando si intende utilizzare le chiavi pubbliche / private.

Le chiavi pubbliche sono pensate per essere condivise, quindi questo è ciò che dovresti usare per scambiare in modo sicuro credenziali, non password con hash.

sudo useradd --disabled-password hbruijn

Quando invii la tua chiave pubblica, verifica l'impronta digitale su un secondo canale, come una telefonata, in modo da sapere che nessuno l'ha modificata durante il suo passaggio.

Dal momento che non avrai una password ora per usare sudo, devi anche modificare la tua linea nel file sudoers

hbruijn ALL=(ALL) NOPASSWD:ALL

Se non hai dimestichezza con la mancanza di password per sudo e desideri davvero una password, non è ancora necessario inviare la password con hash, lasciare che l'account venga creato senza password, impostare la chiave pubblica e una volta che l'account è impostare è possibile accedere tramite ssh ed eseguire passwdper impostare la propria password.

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.