Denna delen av 99 uppdateras inte längre utan har arkiverats inför framtiden som ett museum.
Här kan du läsa mer om varför.
Mac-nyheter hittar du på Macradion.com och forumet hittar du via Applebubblan.

ChrootDirectory och Fedora 13

Tråden skapades och har fått 10 svar. Det senaste inlägget skrevs .
1

Efter några misslyckade försök att använda sig av Google så får det bli dags att vända sig till detta forum för att se om man få en lösning på ett problem.

Senaste SSH-versionen(versionerna?) har fått möjligheten att använda sig av ChrootDirectory, så jag tänkte försöka ge mig in på att hantera det. Rent principiellt så vill jag att varje användarkonto ska se sitt /home som / och därmed inte kunna komma åt filsystemet och annat innehåll som inte ligger under användarens eget konto.

För att lösa detta så testade jag att införa följande i /etc/init.d/sshd_config:

Match User <user>
ChrootDirectory /home/<user>

Detta fungerande dock inte. Det resulterade i följande i /var/log/secure:

Oct 14 14:14:32 li195-128 sshd[4905]: fatal: bad ownership or modes for chroot directory component "/home/<user>/"

Min fråga är därför följande:
Hur gör jag för att få det här att fungera? Ownership är satt till den användare som det var tänkt att låsa in, så det verkar ändå inte vara problemet.

  • Medlem
  • Sollentuna
  • 2010-10-14 15:22

Nja, asså sådär kan du inte göra. <user> är vanlig notation för en godtycklig användare, *men* som ska anges. Det betyder att du ska byta ut <user> på varje förekomst mot en riktig/absolut användare. Du kan göra så här:

Match group sftponly
         ChrootDirectory %h
         X11Forwarding no
         AllowTcpForwarding no
         ForceCommand internal-sftp

Det var ju inte så tokjobbigt att googla...

Ursprungligen av frazze:

Nja, asså sådär kan du inte göra. <user> är vanlig notation för en godtycklig användare, *men* som ska anges. Det betyder att du ska byta ut <user> på varje förekomst mot en riktig/absolut användare. Du kan göra så här:

Match group sftponly
         ChrootDirectory %h
         X11Forwarding no
         AllowTcpForwarding no
         ForceCommand internal-sftp

Det var ju inte så tokjobbigt att googla...

Det som jag hittar via Google (inkl. din länk) är dock just det här med sftponly. Jag vill kunna låsa fast användaren när den loggar in via SSH. Där ligger problemet. Fast det kanske blir så automatiskt även om man lägger in ovanstående kod?

Mitt SFTP på servern är dock avstängt.

  • Medlem
  • Sollentuna
  • 2010-10-14 16:56

Vad menar du med "låsa fast användaren"? På vilket sätt blir det ett problem? Och sftponly är bara en användargrupp som inte har något med SFTP att göra. Den skulle kunna heta users också.

Känns som att du behöver läsa in lite grundläggare *NIX-terminologi innan du ger dig på att ställa in lite mer avancerade saker. Kan det möjligen vara så?

Ursprungligen av frazze:

Vad menar du med "låsa fast användaren"? På vilket sätt blir det ett problem? Och sftponly är bara en användargrupp som inte har något med SFTP att göra. Den skulle kunna heta users också.
Känns som att du behöver läsa in lite grundläggare *NIX-terminologi innan du ger dig på att ställa in lite mer avancerade saker. Kan det möjligen vara så?

Att användaren är låst till %h. Denne ska inte kunna gå ut i t.ex. /home eller /.

Nu har jag faktiskt kommit någonstans, dock. Snickrade ihop följande:

Match User b0ink
ChrootDirectory %h
X11Forwarding no
AllowTcpForwarding no

Det tar mig förbi problemet med rättigheterna. Som jag ser det så gick det inte bra att köra "Match Group <group>" eftersom det inte är en grupp som jag vill låsa in. Rätta mig om jag har fel. Nu har jag dock bara återstående problem och det är den grundläggande shell-strukturen, antar jag.

Tobias-Schelins-MacBook:~ Tobias$ ssh <host> -l b0ink
Last login: Thu Oct 14 16:44:04 2010 from h-38-40.a204.priv.bahnhof.se
/bin/bash: No such file or directory
Connection to <host> closed.

Ovanstående envisas med att dyka upp. Jag försökte göra en symlink till /bin/bash, men det resulterade bara i "Too many levels of symbolic links". Det gick inte heller så bra att kopiera /bin/bash till /home/bin/bash eller /home/b0ink/bin/bash.

Vad gäller att läsa på om grundläggande *NIX-terminologi så jag gör det. Det tar dock tid att lära sig allt, och mycket är "Learn by doing" just nu. Har kommit en bra bit på väg.

  • Medlem
  • Sollentuna
  • 2010-10-14 17:59

Ahhh, jag tror jag förstår nu... Är du med på att det du gör bara är till för SFTP, men du tror att du kan göra en vanlig inloggning med SSH?

Ursprungligen av frazze:

Ahhh, jag tror jag förstår nu... Är du med på att det du gör bara är till för SFTP, men du tror att du kan göra en vanlig inloggning med SSH?

Jag vill kunna göra det för en vanlig inloggning med SSH, ja. Går inte det?

  • Medlem
  • Sollentuna
  • 2010-10-15 08:22
Ursprungligen av Tobias Schelin:

Jag vill kunna göra det för en vanlig inloggning med SSH, ja. Går inte det?

Ja. Läs i dokumentationen så ser du att det endast har att göra med när du kör SFTP - alltså en utökning av SSH. Men vill du göra vanlig inloggning chroot:ad så går det också. Jag tror att du kommer att få upp länkar i samma träfflista.

  • Oregistrerad
  • 2010-10-15 10:21

Förstår inte vad problemet är. Nästan alla NIX system tillåter ju en användare att se rooten av ett filsystem. Oftast kommer du ju inte så mycket längre och /home/-annan-användare kommer du ju aldrig åt iaf pga rättigheter (om man inte satt rättigheterna korkat)

Det är ju ingen bra idé att försöka begränsa detta pga. att man har felaktiga rättigheter i systemet. Det är som att förlita sig på ett villalarm då man inte vet hur man låser dörren. imho

  • Medlem
  • Sollentuna
  • 2010-10-15 10:46

Ja, precis. Framförallt så kommer du inte åt några program alls om du inte explicit ger användaren tillgång till dom, även shellet drabbas av samma sak (som du redan upptäckt...)

Nåja. Det får bli ett dött projekt.

Tack för informationen iaf!

1
Bevaka tråden