Linux: skonfiguruj dla zdalnego administratora


51

Co jakiś czas pojawia się dziwne żądanie zdalnego wsparcia, rozwiązywania problemów i / lub dostrajania wydajności w systemach Linux.

Większe firmy często mają już dobrze ustalone procedury zapewniające zdalny dostęp do dostawców / dostawców, a ja muszę tylko je przestrzegać. (Na dobre i na złe.)

Z drugiej strony małe firmy i osoby niezmiennie zwracają się do mnie z instrukcją, co muszą zrobić, aby mnie skonfigurować. Zazwyczaj ich serwery są bezpośrednio podłączone do Internetu, a istniejące środki bezpieczeństwa obejmują wartości domyślne dla dowolnej dystrybucji Linuksa.

Prawie zawsze będę potrzebować dostępu na poziomie administratora, a ktokolwiek będzie dla mnie konfigurował dostęp, nie jest ekspertem administracyjnym. Nie chcę ich hasła roota i jestem również pewien, że moje działania nie będą złośliwe, ale jakie rozsądnie proste instrukcje powinienem przekazać:

  • załóż konto i bezpiecznie wymień dane uwierzytelniające
  • skonfiguruj dostęp do roota (sudo)
  • ogranicz dostęp do mojego konta
  • zapewnić ścieżkę audytu

(I tak, jestem świadomy i zawsze ostrzegam tych klientów, że kiedy już mam dostęp administratora, ukrywanie złośliwych działań jest banalne, ale załóżmy, że nie mam nic do ukrycia i aktywnie uczestniczę w tworzeniu ścieżki audytu.)

Co można poprawić, wykonując poniższe kroki?


Mój aktualny zestaw instrukcji:

załóż konto i bezpiecznie wymień dane uwierzytelniające

Podaję skrót hasła i proszę o skonfigurowanie mojego konta z tym zaszyfrowanym hasłem, więc nie będziemy musieli przesyłać hasła w postaci zwykłego tekstu, będę jedynym, który zna hasło i nie zaczynamy od przewidywalne słabe hasło.

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

Podaję klucz publiczny SSH (konkretna para kluczy na klienta) i pytam, czy skonfigurowali moje konto z tym kluczem:

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 

skonfiguruj dostęp do roota (sudo)

Proszę klienta, aby skonfigurował dla mnie sudo za pomocą sudo sudoeditlub za pomocą swojego ulubionego edytora i dołączył /etc/sudoers:

hbruijn ALL=(ALL) ALL

ogranicz dostęp do mojego konta

Zazwyczaj klient nadal zezwala na logowanie oparte na hasłach i proszę o dodanie następujących dwóch linii, aby /etc/ssh/sshd_configprzynajmniej ograniczyć moje konto tylko do kluczy SSH:

Match user hbruijn
PasswordAuthentication no

W zależności od klienta przekieruję cały mój dostęp SSH przez jednego hosta bastionu, aby zawsze zapewniał pojedynczy statyczny adres IP (na przykład 192.168.1.2) i / lub podawał zakres adresów IP, z których korzysta mój dostawca usług internetowych (na przykład 10.80. 0,0 / 14). Klient może potrzebować dodać je do białej listy zapory, jeśli dostęp SSH jest ograniczony (najczęściej ssh nie jest jednak filtrowany).

Widziałeś już te adresy IP jako from=ograniczenie w ~.ssh/authorized_keyspliku, które ogranicza hosty, z których mój klucz może być używany do uzyskiwania dostępu do ich systemów.

zapewnić ścieżkę audytu

Do tej pory żaden klient mnie o to nie prosił i nie zrobiłem nic konkretnego poza następującymi czynnościami:

Staram się konsekwentnie używać sudoz poszczególnymi poleceniami i staram się zapobiegać używaniu sudo -ilub sudo su -. Staram się nie używać, sudo vim /path/to/file ale sudoeditzamiast tego używam .

Domyślnie wszystkie akcje uprzywilejowane zostaną następnie zarejestrowane w syslog (i /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

W większości rezygnuję z dostosowywania środowiska pracy, jedyne, co naprawdę robię, to ustawianie następujących elementów w mojej ~/.bash_profilehistorii bashów i dołączanie znaczników czasu:

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
Możesz się zalogować (łatwo zmienić po fakcie), a nawet udostępniać sesje screen, więc w skrajnych przypadkach klient może oglądać na żywo to, co robisz.
Sven

Jeśli chcesz dodać lepszą ścieżkę audytu należy im polecić, aby umożliwić zdalne rejestrowanie jeśli mają możliwość
Fredi

Odpowiedzi:


24

Jedyne, co przychodzi na myśl, to dodanie --expiredatedo adduserrozmowy.
Dzięki temu klient wie, że Twój dostęp wygaśnie automatycznie w określonym terminie.

Nadal musi ci ufać, ponieważ masz dostęp do konta root i nadal może usunąć flagę wygasania.


15

Możesz nagrywać swoje sesje za pomocą narzędzia script (1) .

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

wtedy wszystko jest w session.log.


Czy zaleciłbyś uruchomienie go na własnym hoście przed rozpoczęciem sesji ssh w systemie zdalnym, czy też jako część mojego profilu w systemie zdalnym?
HBruijn

1
Wydaje mi się, że możesz to zrobić - użyłem go tylko wtedy, gdy ludzie tak naprawdę nie dbają.
user9517 obsługuje GoFundMonica 26.09.16

7

Ponieważ już logujesz się przy użyciu klucza publicznego SSH, to trochę zaostrzyłoby się, gdybyś nie podał skrótu hasła; zamiast tego powiedz im, aby użyli adduser --disabled-password(równoważnie, useradd -p '!'jak sądzę), co jest faktycznie równoważne z PasswordAuthentication notym kontem, a ponadto nie ma szans, że ktoś szpiegujący twój adres e-mail mógłby brutalnie wymusić skrót hasła i zalogować się jako Ty.


3
Dodanie Match user hbruijn \n PasswordAuthentication nosshd_config powinno uniemożliwić każdemu zdalne zalogowanie się za pomocą mojego odszyfrowanego hasła (potencjalnie użytkownicy lokalni mogliby go używać su - hbruijn), ale o ile wiem, nadal muszę mieć prawidłowe hasło do sudocelów. Może powinienem po prostu zresetować hasło po zalogowaniu?
HBruijn,

Och, dobra uwaga na temat sudo. Nie jestem pewien, czy konto w --disabled-passwordstanie może otrzymać hasło, uruchamiając je passwdz tego konta.
zwolnić

Co również powstrzymuje każdego, kto nasłuchuje na hasłach, które podajesz? Ta część to słaby link, który podważa użycie kluczy ssh, gdzie nie ma znaczenia, czy twój klucz publiczny został przechwycony.
JamesRyan

3
Czy to słabe łącze można rozwiązać, dodając linię do pliku sudoers, np. hbruijn ALL=(ALL) NOPASSWD: /usr/bin/passwd hbruijn?
Dezza

2

Po co w ogóle podawać hasło, jeśli zamierzasz używać kluczy publicznych / prywatnych.

Klucze publiczne mają być udostępniane, dlatego należy tego używać do bezpiecznej wymiany poświadczeń, a nie mieszania haseł.

sudo useradd --disabled-password hbruijn

Wysyłając swój klucz publiczny, sprawdź odcisk palca na drugim kanale, np. Podczas rozmowy telefonicznej, abyś wiedział, że nikt go nie zmienił po drodze.

Ponieważ nie będziesz już mieć hasła do korzystania z sudo, musisz również zmienić linię w pliku sudoers na

hbruijn ALL=(ALL) NOPASSWD:ALL

Jeśli nie czujesz się komfortowo z brakiem hasła do sudo i naprawdę chcesz hasła, nadal nie musisz wysyłać swojego hasha, pozwól, aby konto zostało utworzone bez hasła, ustaw swój klucz publiczny, a gdy konto zostanie skonfiguruj, możesz zalogować się przez ssh i uruchomić, passwdaby ustawić własne hasło.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.