Puncte:1

De ce același utilizator are parolă și proprietăți de sistem diferite prin autentificarea SSH și GUI (Debian)?

drapel it

Folosesc un VM pe Google Cloud Platform.Odată creat, acesta poate fi accesat prin SSH prin interfața web GCP. Când acces prin SSH, pot folosi sudo pentru a efectua acțiuni privilegiate. Când accesez printr-o metodă GUI, cum ar fi Chrome Desktop sau VNC, nu am privilegii sudo. Cu toate acestea, primesc același nume de utilizator cine sunt in orice caz.

Sunt confuz pentru că am câteva presupuneri:

  • cine sunt indică utilizatorul curent prin numele său.
  • Există un singur utilizator pentru un anumit nume pe întregul sistem și invers.
  • sudo se aplică utilizatorului curent (același ca cine sunt)
  • Proprietățile de autentificare și sudo ale unui utilizator sunt aceleași în întregul sistem.

Dacă acestea sunt adevărate, nu înțeleg cum există diferite sudo comportament când mă conectez în moduri diferite.


Actualizare 3:

am fugit sudo usermod -aG sudo usermod iar după repornire utilizatorul are privilegii sudo peste tot. Nu s-a schimbat nimic în fișierele sudoers. Nu m-am gândit să verific fișierul grupurilor înainte de a face modificarea.

Cred că totul este bine acum din punct de vedere practic. Încă nu înțeleg cum același utilizator poate avea diferite privilegii sudo în locuri diferite.


Actualizare 2:

În /etc/sudoers rândurile necomentate (și directiva) sunt:

Valori implicite env_reset
Valoarea implicită mail_badpass
Valori implicite secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
root ALL=(ALL:ALL) ALL
%sudo ALL=(ALL:ALL) ALL
#includedir /etc/sudoers.d

în sudoers.d este google_sudoers conținând

%google-sudoers ALL=(ALL:ALL) NOPASSWD:ALL

Versiunea sistemului de operare: Debian 10 (buster) Linux 4.19.0-17-cloud-amd64


Actualizați:

Din păcate, poate că ar putea fi cauzat de unele funcții adăugate de Google referitoare la un grup Google-Sudoers.

Jurnalele relevante de la /var/log/auth.log

gpasswd[2309]: utilizatorul user_me adăugat de root la grupul google-sudoers

Sudo reușit:

sudo: user_me : TTY=pts/2 ; PWD=/home/user_me ; UTILIZATOR=rădăcină ; COMMAND=/usr/bin/echo test
sudo: pam_unix(sudo:session): sesiune deschisă pentru utilizator root de user_me(uid=0)
sudo: pam_unix(sudo:session): sesiune închisă pentru utilizator root

Sudo nereușit:

sudo: user_me: utilizatorul NU în sudoers; TTY=pts/0; PWD=/home/user_me ; UTILIZATOR=rădăcină ; COMMAND=/usr/bin/echo test

Încă nu sunt sigur cum poate fi diferit comportamentul pentru același utilizator.

John Hanley avatar
drapel cn
Încercați să adăugați numele dvs. de utilizator în grupul sudo: **sudo usermod -aG sudo username**. Dacă asta rezolvă problema, comparați diferențele.
Goli Nikitha avatar
drapel ng
Aveți nevoie de câteva informații suplimentare pentru a remedia această problemă: 1. Rulați „tail -f /var/log/auth.log” și lăsați fiecare utilizator să se conecteze pentru a vedea dacă există probleme și, de asemenea, rulați „id -a” și furnizați rezultatul. 2. Puteți confirma dacă VM-ul folosește OSLOGIN și imaginea folosită de VM este una furnizată de Google?

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.