Puncte:0

Acces SSH refuzat unui utilizator

drapel in

Întâmpin o eroare în timp ce încerc să mă conectez prin SSH la un server, pentru un utilizator. Directorul principal al acestui utilizator este în /opt, cu un director .ssh (permisiuni: 700) și un fișier authorized_keys care conține cheia publică. Funcționează cu alți utilizatori, cărora directoarele de acasă sunt în /home, folosind aceeași cheie rsa pe care o pot conecta ca alt utilizator. În /var/log/secure primesc:

Apr 8 14:48:22 myserver sshd[338949]: pam_sss(sshd:account): Acces refuzat utilizatorului myuser: 6 (Permisiune refuzată)
8 aprilie 14:48:22 myserver sshd[338949]: fatal: acces refuzat utilizatorului myuser de configurarea contului PAM [preauth]

Folosind ssh -vvv ultimele linii sunt:

debug1: Serverul acceptă cheia: pkalg rsa-sha2-512 blen 535
depanare2: input_userauth_pk_ok: fp SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
depanare3: sign_and_send_pubkey: RSA SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
debug3: trimite pachet: tip 50
Autentificare esuata.

Dacă mă conectez la acest server ca alt utilizator folosind aceeași cheie funcționează, singura diferență pe care o văd este că directorul principal este în /opt în loc de /home. Și acest utilizator are un caracter de subliniere în numele său de conectare. Te-ai confruntat cu astfel de situații?

[EDIT] Informații suplimentare:

SELinux este dezactivat

[root@myserver ~]# getenforce
Dezactivat
[myuser@myserver ~]$ ls -la /opt/myuser/
drwx------ 2 myuser myuser 80 Apr 8 14:46 .ssh
[myuser@myserver ~]# ls -l /opt/myuser/.ssh/authorized_keys
-rw------- 1 utilizatorul meu utilizatorul meu 1131 8 aprilie 14:46 /opt/myuser/.ssh/authorized_keys
[root@myserver ~]# namei -l /opt/myuser/.ssh/authorized_keys
f: /opt/myuser/.ssh/authorized_keys
rădăcină rădăcină dr-xr-xr-x /
drwxr-xr-x root root opt
drwx------ utilizatorul meu utilizatorul meu
drwx------ myuser myuser .ssh
-rw------- myuser myuser chei_autorizate
[root@myserver ~]# grep -v ^# /etc/ssh/sshd_config
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

SyslogFacility AUTHPRIV

PermitRootLogin nr

AuthorizedKeysFile .ssh/authorized_keys

Autentificare prin parolă da

ChallengeResponseAuthentication nr

Autentificare GSSAPI da
GSSAPICleanupCredentials nr

Folosește PAM da

X11 Redirecționare da

AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS

Subsistemul sftp /usr/libexec/openssh/sftp-server
[root@myserver ~]# cat /etc/pam.d/sshd
#%PAM-1.0
auth required pam_sepermit.so
auth substivă parola-auth
auth include postlogin
# Folosit cu polkit pentru a reautoriza utilizatorii în sesiuni la distanță
-auth opțional pam_reauthorize.so pregătiți
cont este necesar pam_nologin.so
contul include parola-auth
parola include parola-auth
# pam_selinux.so close ar trebui să fie prima regulă de sesiune
sesiune necesară pam_selinux.so aproape
sesiune necesară pam_loginuid.so
# pam_selinux.so open ar trebui să fie urmat doar de sesiuni care să fie executate în contextul utilizatorului
sesiune necesară pam_selinux.so deschide env_params
sesiune necesară pam_namespace.so
sesiune opțională pam_keyinit.so forță revocarea
sesiune include parola-auth
sesiunea include postlogin
# Folosit cu polkit pentru a reautoriza utilizatorii în sesiuni la distanță
-session opțional pam_reauthorize.so pregătiți

Autentificarea LDAP este, de asemenea, activată, prin sssd.

drapel in
este implicat selinux?
drapel in
@GeraldSchneider nu, SELinux este dezactivat
drapel in
Ei bine, atunci trebuie să oferi mai multe informații. Configurare SSHd, configurare PAM, mai multe din fișierele dvs. de jurnal (mărește nivelul de jurnal dacă este necesar). Permisiunile reale ar putea fi de asemenea utile (`namei -l` este ideal pentru asta).
drapel in
@GeraldSchneider mulțumesc, am adăugat informații suplimentare în postare
drapel in
Ați omis parametrul `-l` pentru `namei`, care arată informațiile relevante reale.
drapel in
@GeraldSchneider ho, corect, l-am editat. Frumoasă comandă apropo, nu știam.
drapel us
Rob
Pentru mine, mesajul de eroare „Acces refuzat de configurarea contului PAM” sugerează că problema nu este ssh sau permisiunile din fișierul chei, ci cu proprietățile contului (un shell incorect, un grup care nu are permisiunea de a se conecta, un accesul refuzat explicit utilizatorului) - verificați proprietățile contului și poate vedeți dacă există potriviri în `/etc/security`
Puncte:2
drapel cn

Având în vedere că autentificarea LDAP este activată și accesul este refuzat pentru acel utilizator, asta înseamnă că utilizatorului nu i s-a acordat acces în LDAP la acel server.

Puteți verifica /etc/sssd/sssd.conf pentru utilizatori_permiși și grupuri_permise și apoi fie adăugați numele de utilizator ca o intrare a „allowed_users” sau în grupul LDAP menționat în „allowed_groups”

drapel in
într-adevăr, mulțumesc Tewfik. Am făcut o greșeală de tipar când am adăugat utilizatorul la grupul ldap permis să se conecteze. Credeam că e în grup dar DN-ul era incorect. Acum merge, multumesc :)

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.