Hopelijk geen dup, maar kan hier geen antwoord op vinden... Ik vond dit, wat op het eerste gezicht hetzelfde lijkt, maar erg oud is en het enige antwoord erin geen antwoord geeft op de eigenlijke vraag: Set Gebruikers zijn gechroot voor sftp, maar staan ​​de gebruiker toe om in te loggen in SSH

Ik heb met succes een werkende ChrootDirectory-omgeving opgezet via sftp voor gebruikers in de groep 'sftp_users'. Het werkt goed, alle juiste rechten en dergelijke, het beperken van de toegang tot alleen sftp, en ze kunnen rw in hun subdirectory(s) binnen de ChrootDirectory. Dit is geweldig voor niet-bevoorrechte gebruikers, die ssh-toegang niet toestaan ​​en alleen rw toestaan ​​in hun submap(pen) in de ChrootDirectory.

Ik zou graag wat meer geprivilegieerde gebruikers hebben die nog steeds normaal ssh kunnen gebruiken, maar als ze inloggen via sftp dan hebben ze de ChrootDirectory-omgeving. Dit is minder een beveiligingsprobleem, omdat ze als geprivilegieerd worden beschouwd en obvi in ​​ssh door het bestandssysteem kan surfen binnen hun normale gebruikersrechten. Het probleem is dat ik geen manier zie om ze te Chroot wanneer ze inloggen onder sftp zonder ssh-aanmelding te voorkomen. Dit is meer voor standaardisatie en gemak dan wat dan ook, dus wanneer ze sftp komen ze gewoon aan op hun Chrooted-locatie zoals de sftp-only gebruikers.

Ik dacht dat dit zou werken als ik hun shell als standaard zou laten (niet /bin/false of nologin). Helaas, als ze zich in de groep sftp_only bevinden, kunnen ze helemaal niet ssh-en, alleen sftp. Is hier een oplossing voor, behalve dat er twee aparte accounts zijn: één toegevoegd aan 'sftp_users' en één niet in die groep? Tot nu toe kan ik alleen documentatie vinden over het beperken van de sftp-chroot en het tegelijkertijd verbieden van ssh als ze in die groep zitten.

Voorbeeldgebruiker is 'test'. 'test' zit in de sftp_users groep, en kan daarom inloggen via sftp en gechroot worden naar zijn gespecificeerde map ('/sftp/test') en lezen of schrijven naar zijn thuismap bind-gemount op '/sftp/test/home' . Dit werkt allemaal. Maar zelfs als zijn shell nog steeds is ingesteld in /etc/passwd naar /bin/bash, kan 'test' niet inloggen via ssh als het is toegevoegd aan de groep sftp_users. Verwijder het lidmaatschap van die groep en hij kan beide doen, maar dan niet Chrooted onder sftp.

Gebruikers die niet in de groep 'sftp_users' zitten kunnen nog steeds inloggen via ssh of sftp, maar zijn niet gechroot onder sftp.

Is er een manier om te matchen welk protocol wordt gebruikt, en/of misschien een extra Match in te stellen voor een andere groep? Ik ben alleen op zoek naar de chroot wanneer ze inloggen via sftp. De niet-chroot via ssh is prima voor deze gebruikers.

Hieronder volgt mijn sshd_config:

Port XXXX
#ListenAddress ::
#ListenAddress 0.0.0.0

Protocol 2

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

SyslogFacility AUTH
LogLevel INFO

LoginGraceTime 120
PermitRootLogin no
StrictModes yes

PubkeyAuthentication yes

IgnoreRhosts yes
HostbasedAuthentication no

PermitEmptyPasswords no

ChallengeResponseAuthentication no

X11Forwarding yes
X11DisplayOffset 10
PrintMotd yes
PrintLastLog yes

ClientAliveCountMax 10
ClientAliveInterval 3600
TCPKeepAlive no

#Banner /etc/issue.net

AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server -u 0027

UsePAM yes
PasswordAuthentication yes



Match Group sftp_users
  ChrootDirectory /sftp/%u
  ForceCommand internal-sftp -u 0027
  X11Forwarding no
  AllowTcpForwarding no
  PasswordAuthentication yes
answer

OpenSSH biedt geen ondersteuning voor het overschrijven van algemene trefwoorden op basis van de verzonden opdracht. Je moet differentiëren op een aantal (combinatie van) criteria die OpenSSH biedt voor de Matchverklaring.

The available criteria are User, Group, Host, LocalAddress, LocalPort, RDomain, and Address (with RDomain representing the rdomain(4) on which the connection was received)

-- man 5 sshd_config

Een veelvoorkomende keuze is het aanbieden van opzettelijk beperkte services op alternatieve IP's die worden bereikt via alternatieve domeinen, zoals snapshot.backup.exampleen sftp.backup.example.


De opmerkingen over de gekoppelde vraag beschrijven het probleem echter duidelijk.

Als u denkt dat u sftp -toegang gechroot wilt hebben voor geprivilegieerde gebruikers, verwart u waarschijnlijk verschillende rollen in identieke gebruikers , en dat brengt beveiligingsrisico's met zich mee. Meestal worden problemen met audits en scheiding van bevoegdheden beter gediend door een andere gebruiker te gebruiken voor alles wat u heeft doen overwegen om chroot-instellingen in te stellen, zelfs voor gebruikers die daar niet door worden beperkt. Als er twee verschillende taken zijn, zelfs als deze door dezelfde persoon worden uitgevoerd , en één is veiliger als het opzettelijk wordt beperkt, stel dan een nieuwe systeemgebruiker in (bijv. gebruik een gebruiker personen person-taskdeel de meeste beperkingen en authenticatiemethoden, en beperk er slechts één van hen in ssh).