TDLR: Am un Catch 22 în care, în funcție de permisiunile din directorul principal al utilizatorului, pot face ca autentificarea SSH să funcționeze sau constrângerile directorului utilizatorului, dar nu ambele.
BTW, chiar vreau să-mi rulez propriul server SFTP. Vă rugăm să nu recomandați să încerc serviciul AWS Transfer sau ceva alternativ. Mulțumiri.
Aici este conținut relevant (modificat din implicit) în /etc/ssh/sshd_config:
Subsistem sftp intern-sftp
Portul 22
Portul 2299
Potriviți grupul sftpusers LocalPort 2299
ChrootDirectory /sftp-data/%u
ForceCommand intern-sftp
Potriviți grupul sftpusers LocalPort 22
DenyGroups sftpusers
Potriviți Grupul LocalPort 2299 *,!sftpusers
DenyUsers *
Vreau ca portul 22 să funcționeze ca de obicei ssh, dar numai pentru utilizatorii non-sftp. Pentru utilizatorii sftp, în grupul „sftpusers”, vreau ca portul 2299 să funcționeze numai ca sftp, și nu ca ssh. Pentru utilizatorii non-sftpusers, vreau accesul la portul 2299 refuzat.
Ok, deci, am creat un utilizator „user1” cu directorul principal /sftp-data/user1 și shell /sbin/nologin. Am creat /sftp-data/user1/.ssh/authorized_keys și l-am populat cu cheia publică ssh. /sftp-data este deținut de root cu 700 de permisiuni. /sftp-data/user1/.ssh și mai jos sunt deținute de user1, iar /sftp-data/user1/.ssh/authorized_keys are permisiunea 600. Proprietatea/permisiunile /sftp-data/user1 sunt sub semnul întrebării aici. Mai multe mai jos.
Am creat grupul de utilizatori sftpusers și am adăugat user1 la acel grup. Cu toate acestea, utilizatorul ec2 încorporat pe care îl obțineți cu AWS nu este membru al grupului respectiv. Testarea cu ec2-user a funcționat excelent: accesul prin ssh, portul 22 a funcționat ca întotdeauna, dar nu avea acces la portul 2299.
Deci, testarea cu user1 este locul unde a devenit interesant. User1 nu are acces la portul 22 - asta e grozav! Cu user1 deținând /sftp-data/user1, autentificarea cu cheie publică ssh reușește pe portul 2299, dar utilizatorul este imediat deconectat, cu acest mesaj salvat în /var/log/secure:
2 septembrie 19:21:38 ip-192-168-0-25 sshd[10369]: cheie publică acceptată pentru utilizatorul 1 de la <adresa-ip redactată> portul 61110 ssh2: ECDSA SHA256:<adresa-ip redactată>
2 septembrie 19:13:23 ip-192-168-0-25 sshd[9803]: pam_unix(sshd:session): sesiune deschisă pentru utilizatorul user1 de (uid=0)
2 septembrie 19:13:23 ip-192-168-0-25 sshd[9803]: fatal: proprietate proastă sau moduri pentru directorul chroot „/sftp-data/user1” [postauth]
2 septembrie 19:13:23 ip-192-168-0-25 sshd[9803]: pam_unix(sshd:session): sesiune închisă pentru utilizatorul user1
Sigur, asta are sens. Chroot necesită ca /sftp-data/user1 să fie deținut de root, permisiuni 700. Așadar, faceți acest lucru, iar acum autentificarea sftp (cheie ssh) eșuează.
2 septembrie 19:41:00 ip-192-168-0-25 sshd[11693]: eroare: AuthorizedKeysCommand /opt/aws/bin/eic_run_authorized_keys user1 SHA256:<sha redactat> a eșuat, starea 22
BTW, eic_run_authorized_keys este un wrapper pe care AWS îl pune în jurul autentificării ssh standard pentru a activa AWS Instance Connect.
Pentru credit suplimentar... dacă problema de mai sus nu este suficient de provocatoare, puteți veni cu o schemă în care să pot oferi anumitor utilizatori sftp acces la anumite directoare de proiecte și numai la acelea, fără a crea un grup pentru fiecare proiect? Legătura de la directorul principal al fiecărui utilizator la un director de proiect ar fi minunat.
Informații suplimentare solicitate de @anx:
# getent passwd user1
user1:x:1001:1001::/sftp-data/user1:/sbin/nologin
# namei -l /sftp-data/user1/.ssh/authorized_keys
f: /sftp-data/user1/.ssh/authorized_keys
rădăcină rădăcină dr-xr-xr-x /
drwxr-xr-x root root sftp-data
drwx------ root root user1
drwx------ user1 sftpusers .ssh
-rw------- user1 sftpusers chei_autorizate
Am activat înregistrarea DEBUG pentru sshd. Folosind directiva ChrootDirectory, cu /sftp-data/user1 deținut de root și autentificarea SSH eșuând, văd asta în /var/log/secure:
debug1: Nu s-au putut deschide cheile autorizate „/sftp-data/user1/.ssh/authorized_keys”: Permisiune refuzată
ps îmi arată clar că root rulează procesul sshd.
