Głupota: Nic nie zatrzyma Cię przed zrobieniem dowolnej głupoty. W wypadku pracy na koncie dowolnego innego użytkownika, zanim zaczniesz wprowadzać zmiany w systemie, będziesz musiał podać hasło (czy to roota, czy własne poprzez sudo), co sprawia, że w trakcie pracy zatrzymasz się na chwilę, co pozwoli Ci zastanowić się, czy aby na pewno to co robisz nie okaże się potem problemem, czy na pewno jest to potrzebne etc.
Bezpieczeństwo: Wszędzie można natknąć się na głosy, że praca na koncie root to poważna luka w zabezpieczeniach naszego systemu, ale mało kiedy towarzyszy temu jakieś wyjaśnienie. Otóż otwarta praca na koncie root, której często towarzyszy otwarcie możliwości np logowania bezpośredniego przez SSH na to konto sprawia, że potencjalny haker zna już połowę potrzebnych danych, aby dostać się do maszyny i ją przejąć! Większość takich “hakerów” w dzisiejszych czasach to boty. One się nie zastanawiają, po prostu znajdują port z SSH na naszym serwerze (zmiana portu SSH nie pomoże, prędzej czy później i tak się dobiorą) i dobijają się do niego, próbując złamać nasze hasło do konta root. Jeżeli zamiast konta root przerzucimy się na konto, którego loginem będzie nasz nick, bądź nasze imię, a logowanie na roota zablokujemy, to nasz serwer stanie się w zasadzie nieosiągalny dla typowych botów włamujących się.
Dodatkowa ochrona przed błędami aplikacji: Programista też człowiek, zdarzy mu się popełnić błąd. Przykładowo czasami zdarza się, że przez błąd programisty jakiś serwer gry się zawiesi. Czasem się scrashuje. To nie są jakieś ogromne problemy, błąd można zgłosić, serwer zrestartować i żyje się dalej. Gorzej, jeżeli przez błąd w aplikacji ktoś może włamać się na nasz serwer i wykonywać operacje na systemie operacyjnym. Takie błędy również się zdarzają i trzeba być na nie przygotowanym. Jeżeli uruchamiamy nasze serwery np. gier poprzez konto root, a potem w silniku serwera zostanie znaleziony błąd pozwalający wykonywać polecenia w systemie operacyjnym, to w zasadzie nasz VPS lub dedyk nadaje się tylko do przeinstalowania - włamywacz poprzez serwer gry mógł nam podłożyć na serwer dowolne świństwo, które niekoniecznie musi zadziałać od razu, dlatego dla pewności trzeba wyrzucić z naszej maszyny wszystko. W wypadku w którym nasz serwer gry zostaje odpalony przez oddzielne konto, włamywacz nie może nic więcej niż to konto - w przypadku możliwości włamania wystarczy usunąć wszystkie pliki konta z którego uruchamiamy serwer i postawić go od nowa. To znacznie mniej roboty.
Nie potrzebujesz tego: Jeżeli musisz wykonać pojedyncze komendy z prawami roota, wystarczy skorzystać z su root -c 'polecenie', np: apt-get upgrade
zamieniamy w: su root -c 'apt-get upgrade'
Ktoś może mi zarzucić, że przecież w internecie jest masa poradników, nawet tych dosyć świeżych, które np. mówią, żeby wykonywać podawane polecenia z poziomu konta root. Niestety, wiele osób żyje jeszcze starym podejściem do konta root, gdyż podejście do odchodzenia od tego konta ze względów bezpieczeństwa jest względnie nowe. Warto dbać o bezpieczeństwo naszego serwera, warto nieużywać roota. Nie przyjmujmy wszystkich poradników bezkrytycznie, nawet jeżeli kupujemy serwer vps tylko po to, żeby nie przepłacać za hosting naszych serwerów gier na hostingach współdzielonych, to usiądźmy na chwilę i zastanówmy się, co będzie dla nas lepsze na dłuższą metę.
Poradnik typowy dla potocznego Kowalskiego który ma styczność z Linux’em tylko na VPS etc. itp. acz również dla wielkich znawców których to nie brakuje na każdym forum ( bo on ma Linux’a ale pyta się jak zaktualizować system bo mu się np: program w gui się nie odpala )
no ja bym dodał jeszcze jedną opcję:
user@vpsxxx su
hasło
root@vpsxxx apt install paczka
osobiście jak coś u kogoś robię stosuję tą metodę
a po wykonaniu pracy wystarczy
root@vpsxxx exit
user@vpsxxx
Zawsze jak coś można zrobić z konta użytkownika to poco robić to z konta root'a
Nie ma sensu używać tutaj ‘sudo’ skoro praktycznie to samo można osiągnąć używając komendy ‘su’ np w taki sposób:
su root -c 'echo hello world'
Dodatkowo ‘su’ jest wymagane przez standardy takie jak SUS/POSIX, nie trzeba nic doinstalowywać, jest dostępne we wszystkich systemach z rodziny *nix. ‘sudo’ może przydać się do tworzenia złożonej polityki bezpieczeństwa ale trzymanie go tylko do takiego celu który jest zaprezentowany powyżej jest troche niepotrzebne.
Ale ogólnie poradnik świetny, napewno się tutaj przyda.
Usunąłem folder /var/lib na rocoie i wykonałem restart (bo głupi wszedłem na jakieś obojętne źródło) i nie mogłem instalować pakietów i tym podobnym. Nie było innego wyjścia niż reinstalacja systemu.
To jak już się tu coś dzieje to i ja podam swój - omsknęła mi się myszka pracując przez FTP i przeniosłem folder lib64 do folderu var. W ten sposób skutecznie zabiłem sobie na VPSie wszystko poza już otwartą sesją SSH i chyba tylko komendą ls. System udało się naprawić, ale zajęło to 2 dni i użycie np. rescue mode. Nie polecam roota i śliskich rąk
Jeżeli chodzi o pkt. Nr. 2 to można się logować jako root przez ssh ale wystarczy skonfigurować ssh aby logować się tylko przy pomocy kluczy szyfrujących a taki bot nie złamie klucza RSA.
Co do WinSCP: widzisz, z root-em łatwiej, WinSCP nie ma sudo - wniosek prosty
Co do kluczy - 100x bezpieczniejsze niż hasła, no, chyba że wrzucasz swój klucz prywatny gdzieś do internetu
Jeżeli chodzi o hasło do klucza - nie ma to większego znaczenia z punktu widzenia bota który nie ma tego klucza. Jeżeli masz naraz dozwolone logowanie kluczem i hasłem, to bot może łamać hasło i nie przejmować się kluczem.
Hasło i klucz to 2 oddzielne sposoby uwierzytelniania. Jak masz hasło i klucz to możesz się logować zarówno hasłem jak i kluczem. Przy takiej konfiguracji po złamaniu hasła klucz do niczego potrzebny nie jest. (Nie trzeba klucza, żeby się zalogować)
kozystałem z jednego poradnika i tam było napisane ze klucz dodatkowo zabezpieczony hasłem zwieksza bezpieczeństwo, ze jak sie logujesz kluczem to musisz jeszcze wpisywac hasło
Klucz zabezpieczony hasłem sprawia, że jeżeli plik z kluczem dsotanie się w niepowołane ręce, to jeszcze trzeba złamać do niego hasło, ale jeżeli dobrze pilnujesz pliku, to w zasadzie nic się nie zmienia.
Dlatego najlepiej mieć klucz (zabezpieczony hasłem, wybierasz to podczas generowania klucza) oraz wyłączone logowanie poprzez hasło na serwerze - logowanie wyłącznie za pomocą właściwych kluczy.
