Vraag Hoe kan ik sftp-alleen SSH-gebruikers in hun huis chrooten?


Ik wil een client toegang geven tot mijn server, maar ik wil die gebruikers beperken tot hun persoonlijke mappen. Ik zal bind-mount in alle bestanden die ik wil dat ze kunnen zien.

Ik heb een gebelde gebruiker gemaakt bob en heeft hem toegevoegd aan een nieuwe groep met de naam sftponly. Ze hebben een homedirectory op /home/bob. Ik heb hun shell gewijzigd in /bin/false om SSH-aanmeldingen te stoppen. Hier is hun /etc/passwd lijn:

bob:x:1001:1002::/home/bob:/bin/false

Ik heb ook de /etc/ssh/sshd_config om het volgende op te nemen:

Match Group sftponly
        ChrootDirectory /home/%u
        ForceCommand internal-sftp
        AllowTcpForwarding no

Wanneer ik probeer in te loggen als zij, hier is wat ik zie

$ sftp bob@server
bob@server's password: 
Write failed: Broken pipe
Couldn't read packet: Connection reset by peer

Als ik het commentaar geef ChrootDirectory regel kan ik SFTP in, maar dan hebben ze de vrije hand over de server. Ik heb dat gevonden ChrootDirectory /home werkt, maar het geeft ze nog steeds toegang tot elke homedirectory. Ik heb het expliciet geprobeerd ChrootDirectory /home/bob maar dat werkt ook niet.

Wat doe ik verkeerd? Hoe kan ik beperken bob naar /home/bob/?

----BEWERK-----

Oké, dus ik heb er gewoon naar gekeken /var/log/auth.log en zag dit:

May  9 14:45:48 nj sshd[5074]: pam_unix(sshd:session): session opened for user bob by (uid=0)
May  9 14:45:48 nj sshd[5091]: fatal: bad ownership or modes for chroot directory component "/home/bob/"
May  9 14:45:48 nj sshd[5074]: pam_unix(sshd:session): session closed for user bob

Ik weet niet helemaal zeker wat daar gebeurt, maar het suggereert dat er iets mis is met de gebruikersdirectory. Hier is de ls -h /home output:

drwxr-xr-x 26 oli      oli      4096 2012-01-19 17:19 oli
drwxr-xr-x  3 bob      bob      4096 2012-05-09 14:11 bob

111
2018-05-09 13:43


oorsprong


ik geloof ChrootDirectory /home/%u kan vervangen worden ChrootDirectory %h. - Franck Dernoncourt


antwoorden:


Al deze pijn is te danken aan verschillende beveiligingsproblemen zoals hier beschreven. In principe moet de chroot-directory eigendom zijn van root en kan geen groepsschrijftoegang zijn. Heerlijk. Dus je moet in wezen je chroot veranderen in een holdingcel en daarbinnen dat je kunt je bewerkbare inhoud hebben.

sudo chown root /home/bob
sudo chmod go-w /home/bob
sudo mkdir /home/bob/writable
sudo chown bob:sftponly /home/bob/writable
sudo chmod ug+rwX /home/bob/writable

En bam, u kunt inloggen en erin schrijven /writable.


111
2018-05-09 14:21



Heel erg bedankt bedankt. Twee problemen echter. 1.) Hoewel ik niet kan schrijven, kan ik nog steeds door het hele bestandssysteem bladeren. 2.) Shell veranderen naar / bin / false voorkomt SFTP volledig. Doe ik iets fout? - kim3er
Dank je! Veel andere artikelen over dit onderwerp missen dit detail, en sommige zorgen ervoor dat de server ssh-verbindingen niet accepteert (wat een rotzooi is als je op EC2 zit en ... dat is de enige manier). - Tom Harrison Jr
kim3er: dit is omdat je de shell van de gebruiker moet instellen op / sbin / nologin - / bin / false schakelt elke soort toegang uit.
Ik wil ook opmerken dat alle mappen die naar uw chroot-map leiden eigendom moeten zijn van root. In dit voorbeeld /home moet ook eigendom zijn van root. - Shiki
Op 14.04 moest ik ook de Subsystem sftp /usr/lib/openssh/sftp-server regel naar Subsystem sftp internal-sftp -f AUTH -l VERBOSE voordat dit werkte. - partofthething


Om een ​​SFTP-map te chroot, moet u dit doen

  1. Maak een gebruiker en forceer root om er eigenaar van te zijn

    cd /home
    mkdir john
    useradd -d /home/john -M -N -g users john
    sudo chown root:root /home/john
    sudo chmod 755 /home/john
    
  2. Wijzig de subsysteemlocatie op / etc / ssh / sshd_config:

    #Subsystem sftp /usr/lib/openssh/sftp-server
    Subsystem sftp internal-sftp
    

    en maak een gebruikerssectie aan het einde van het bestand (ssh kan sterven respawning indien geplaatst na subsysteemregel):

    Match User john
        ChrootDirectory /home/john
        ForceCommand internal-sftp
        AllowTCPForwarding no
        X11Forwarding no
    

52
2017-10-25 17:54



zonder het laatste deel te doen (een gebruikersgedeelte aanmaken) werkte niets! dank je - Sinan Erdem
dit lijkt niet te werken. in uw voorbeeld de gebruiker john is vergrendeld op de /home/john directory. je hebt toegegeven 755 rechten voor de map. dus de eigenaar heeft (4) gelezen, geschreven (2) en uitgevoerd (1), en de groep heeft gelezen (4) en uitgevoerd (1). je hebt ook de eigenaar en groep ingesteld als root, dus john behoort tot andere. hij heeft ook gelezen en uitgevoerd (4 + 1 = 5). dus je hebt john opgesloten in een map waar hij geen schrijfrechten heeft. hoe dit te repareren? privileges wijzigen in 757 of zelfs 777 breekt de login. het wijzigen van de groep of eigenaar in john breekt ook met inloggen. - Daniel
ook om op te merken: in / etc / ssh / sshd_config worden de configs in volgorde gelezen. Dus als u een regel heeft voor gebruikers in het algemeen en u wilt er één overschrijven, plaats dan de gebruikersspecifieke regel bovenaan. - rwenz3l
Ik wil een SFTP-map chroot in de thuismap van een andere gebruiker. Ik heb userx op /home/userx/sftproot/uploadsen sftpuser op / home / sftpuse. Ik heb chroot ingesteld op /home/usex/sftproot eigendom zijn van root: root en chmod 755. Het /home/usex/sftproot/uploads is chown-ed door sftpuser: sftpuser. Ik krijg dezelfde fout als de oorspronkelijke vraag hierboven. Moeten de chroot- en alle bovenliggende mappen eigendom zijn van root: root zodat sftp kan werken? - Primoz Rome


Ik heb de hele dag geprobeerd om een ​​netwerkaandeel op mijn framboos te krijgen. Ik wilde de gebruiker vergrendelen zodat hij niet door het hele bestandssysteem kon navigeren, geen SSH-inlogtoegang had en ik schrijftoegang tot de netwerkshare wilde hebben.

En hier is hoe ik het heb laten werken:

Eerst maakte ik een gebruiker:

sudo useradd netdrive

Vervolgens bewerkt /etc/passwd en ervoor gezorgd dat het heeft /bin/false voor de gebruiker, dus de regel was:

netdrive:x:1001:1004:Net Drive User,,,:/home/netdrive:/bin/false

Ik heb bewerkt /etc/ssh/sshd_config opnemen:

Match User netdrive
  ChrootDirectory /home/netdrive
  ForceCommand internal-sftp
  AllowTcpForwarding no
  X11Forwarding no

De eigenaar en machtigingen van de huisdirectory zijn gewijzigd:

sudo chown root:root /home/netdrive/
sudo chmod 755 /home/netdrive/

Oké, na dit alles kon ik verbinding maken via sshfs maar in de alleen-lezen modus. Wat ik moest doen om een ​​beschrijfbare map te krijgen:

sudo mkdir -p /home/netdrive/home/netdrive/
sudo chown netdrive:netdrive /home/netdrive/home/netdrive/
sudo chmod 755 /home/netdrive/home/netdrive/

Dat was het, het werkte zonder verdere veranderingen. Merk op dat ik alleen schrijfbare rechten heb voor de gebruiker, niet naar de groep zoveel andere online oplossingen. Ik kon zonder problemen bestanden / mappen aanmaken / verwijderen / bewerken / hernoemen.

Bij toegang tot gebruiken sshfs met de NetDrive gebruiker vanwege chroot-configuratie Ik zou alleen dingen zien die in de server zijn opgeslagen /home/netdrive/ map, perfect. Het herhaalde /home/netdrive/home/netdrive/ mapstructuur is wat ervoor zorgde dat het voor mij schoon was schrijf ssch schrijfbaar oplossing.

Nu ga ik de problemen die ik had hieronder uitleggen:

Voer de volgende paragrafen waarschijnlijk niet uit:

Na het bekijken van de bovenstaande oplossingen (en vele anderen op het net die zelfs acl gebruikten (toegangscontrolelijsten)) Ik kon het nog steeds niet laten werken, want wat ik vervolgens deed was:

Het volgende deed NIET werk voor mij:

sudo mkdir /home/netdrive/writable/
sudo chown netdrive:netdrive /home/netdrive/writable/
sudo chmod 755 /home/netdrive/writable/

Omdat het NetDrive gebruiker kon daar nog steeds niet in schrijven /home/netdrive/writable/ directory ondanks het bezit van de map en het hebben van de permissies. Toen deed ik:     sudo chmod 775 / home / netdrive / schrijfbaar / En nu kon ik een map maken en verwijderen, maar ik kon deze niet bewerken omdat deze werd gemaakt zonder beschrijfbare rechten voor groepen. Hieruit wat ik zag op het net dat mensen gebruiken acl om het te repareren. Maar daar was ik niet blij mee omdat ik het moest installeren acl, stel mount-punten in, etc. Ook heb ik geen idee waarom ik het nodig zou hebben groep toestemming om te schrijven naar een map die eigendom is van dezelfde gebruiker.

Het lijkt erop dat om de een of andere reden creëren /home/netdrive/home/netdrive en het eigendom aan de laatste geven netdrive map Ik kon alles laten werken zonder er iets mee te doen groep toestemmingen.


4
2017-07-18 17:58