Vraag Linux: instellen voor remote sysadmin


Af en toe krijg ik het vreemde verzoek om ondersteuning op afstand, probleemoplossing en / of het afstemmen van prestaties op Linux-systemen te bieden.

Grotere bedrijven hebben vaak al gevestigde procedures om externe toegang tot leveranciers / leveranciers te bieden en ik hoef daar alleen aan te voldoen. (In voor-en tegenspoed.)

Aan de andere kant wenden kleine bedrijven en individuen zich altijd tot mij om hen te leren wat ze moeten doen om me op te zetten. Doorgaans zijn hun servers direct verbonden met het internet en bestaan ​​de bestaande beveiligingsmaatregelen uit de standaardinstellingen voor elke Linux-distributie.

Bijna altijd heb ik toegang op rootniveau nodig en wie de toegang voor mij wil instellen, is geen expert-systeembeheerder. Ik wil hun root-wachtwoord niet en ben er ook vrij zeker van mijn acties zal niet kwaadaardig zijn, maar welke redelijk eenvoudige instructies moet ik geven:

  • een account opzetten en veilig inloggegevens uitwisselen
  • stel root (sudo) toegang in
  • toegang tot mijn account beperken
  • verstrek een audit trail

(En ja ik ben me ervan bewust en waarschuw altijd die klanten dat zodra ik de toegang van de beheerder heb om kwaadaardige acties te verbergen, triviaal is, maar laten we aannemen dat ik niets te verbergen heb en actief deel te nemen aan het maken van een audittrail.)

Wat kan er verbeterd worden in de onderstaande stappen?


Mijn huidige instructieset:

een account opzetten en veilig inloggegevens uitwisselen

Ik verstrek een wachtwoordhash en vraag dat mijn account is ingesteld met dat gecodeerde wachtwoord, dus we hoeven geen duidelijk tekstwachtwoord te verzenden, ik ben de enige die het wachtwoord kent en we beginnen niet met een voorspelbaar zwak wachtwoord.

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

Ik geef een openbare SSH-sleutel (specifiek sleutelpaar per client) en vraag of ze mijn account met die sleutel instellen:

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 

stel root (sudo) toegang in

Ik vraag de client om sudo voor mij op te zetten sudo sudoedit of door hun favoriete editor te gebruiken en eraan toe te voegen /etc/sudoers:

hbruijn ALL=(ALL) ALL

toegang tot mijn account beperken

Doorgaans staat de client nog steeds aanmeldingen op basis van wachtwoorden toe en ik vraag ze om de volgende twee regels toe te voegen /etc/ssh/sshd_config om op zijn minst mijn account te beperken tot alleen SSH-sleutels:

Match user hbruijn
PasswordAuthentication no

Afhankelijk van de client rouleer ik al mijn SSH-toegang via een enkele bastionhost om altijd een enkel statisch IP-adres (bijvoorbeeld 192.168.1.2) te verstrekken en / of het IP-adresbereik te bieden dat mijn ISP gebruikt (bijvoorbeeld 10.80. 0.0 / 14). De client moet deze mogelijk toevoegen aan de witte lijst van een firewall als de SSH-toegang beperkt is (vaker is ssh echter niet gefilterd).

Je hebt die ip-adressen al gezien als de from= beperking in de ~.ssh/authorized_keys bestand dat de hosts beperkt vanwaar mijn sleutel kan worden gebruikt om toegang te krijgen tot hun systemen.

verstrek een audit trail

Tot nu toe heeft geen enkele klant me hierom gevraagd en ik heb verder niets specifieks gedaan ter dekking van mijn kont:

Ik probeer consistent te gebruiken sudo met individuele commando's en probeer het gebruik ervan te voorkomen sudo -i of sudo su -. Ik probeer het niet te gebruiken sudo vim /path/to/file  maar gebruik sudoedit in plaats daarvan.

Standaard worden alle geprivilegieerde acties vastgelegd in syslog (en /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

Ik heb het meestal opgegeven om mijn werkomgevingen aan te passen, het enige dat ik echt doe, is het volgende in mijn ~/.bash_profile het vergroten van de bash-geschiedenis en het opnemen van tijdstempels:

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

50
2017-09-26 11:54


oorsprong


U kunt inloggen (gemakkelijk te wijzigen na het feit) en zelfs sessies delen in screen, dus in extreme gevallen kan uw klant live bekijken wat u doet. - Sven♦
Als u een beter audit-trail wilt toevoegen, moet u hen opdracht geven om remote logging in te schakelen als ze de mogelijkheid hebben - Fredi


antwoorden:


Het enige dat in je opkomt, is toevoegen --expiredate naar de adduser noemen.
Daarmee weet de klant dat uw toegang automatisch vervalt op een vaste datum.

Hij moet je nog steeds vertrouwen, want je hebt root-toegang en je kunt de verval-vlag toch verwijderen.


24
2017-09-26 12:34





U kunt uw sessies opnemen met de script (1) nut.

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

dan alles zit in session.log.


15
2017-09-26 16:29



Zou je aanraden om dat op je eigen host uit te voeren, voordat je de ssh-sessie start met een systeem op afstand of het opnemen als onderdeel van mijn profiel op het externe systeem? - HBruijn
Ik veronderstel dat je het ook zou kunnen doen - ik heb het maar één keer gebruikt, meestal maakt het mensen niet zoveel uit. - Iain


Omdat je al inlogt met een publieke SSH-sleutel, zou het iets strakker worden als je geen wachtwoord-hash hebt opgegeven; in plaats daarvan vertel ze om te gebruiken adduser --disabled-password (Equivalent, useradd -p '!', Denk ik), wat in feite gelijkwaardig is aan PasswordAuthentication no voor dat account, plus er is geen kans dat iemand die op je e-mail snuffelt, de wachtwoordhash brute-forceert en inlogt als jij.


7
2017-09-26 15:51



De toevoeging van de Match user hbruijn \n PasswordAuthentication no om sshd_config te voorkomen dat iemand op afstand kan inloggen met mijn ontsleutelde wachtwoord (mogelijk kunnen lokale gebruikers het gebruiken met su - hbruijn) maar voor zover ik weet moet ik nog steeds een geldig wachtwoord hebben sudo doeleinden. Misschien moet ik gewoon mijn wachtwoord opnieuw instellen na het inloggen? - HBruijn
Oh, goed punt over sudo. Ik weet niet zeker of een account in --disabled-password status kan een wachtwoord krijgen door te lopen passwd van dat account. - zwol
En wat houdt iemand tegen die luistert naar de wachtwoord-hasj die u verstrekt? Dat deel is een zwakke schakel die het gebruik van ssh-sleutels ondermijnt, waarbij het niet uitmaakt of uw openbare sleutel wordt onderschept. - JamesRyan
Zou die zwakke link kunnen worden opgelost door de cliënt ook een regel toe te voegen in het sudoers-bestand zoals hbruijn ALL=(ALL) NOPASSWD: /usr/bin/passwd hbruijn? - Dezza


Waarom zou u een wachtwoord opgeven als u openbare / privé-sleutels gaat gebruiken?

Publieke sleutels zijn bedoeld om gedeeld te worden, dus dit is wat u moet gebruiken om veilig referenties uit te wisselen, niet gehashte wachtwoorden.

sudo useradd --disabled-password hbruijn

Wanneer u uw openbare sleutel verzendt, verifieert u de vingerafdruk op een tweede kanaal, zoals een telefoongesprek, zodat u weet dat niemand het op zijn weg heeft gewijzigd.

Omdat je nu geen wachtwoord meer hebt om sudo te gebruiken, moet je ook je regel in het sudoers-bestand wijzigen in

hbruijn ALL=(ALL) NOPASSWD:ALL

Als u niet vertrouwd bent met het hebben van geen wachtwoord voor sudo en u echt een wachtwoord wilt, hoeft u uw gehashte wachtwoord nog steeds niet te verzenden, het account zonder wachtwoord te maken, uw openbare sleutel in te stellen en uw account eenmaal je kunt je aanmelden via ssh en uitvoeren passwd om uw eigen wachtwoord in te stellen.


2
2017-09-30 09:12