Problem med rättigheter för sftp användare

• Hur tog du bort möjligheten att logga in med root, var det i sshd_config?

• Är du säker på att du inte förstörde filen i samband med detta?

• Har det alltid gått att ladda upp filer med sftp-användaren?

• Har du kollat vad det står i loggen för sshd? Du behöver kanske öka log level för att få användbar information.

loggar du in som användaren så kan du bara hantera användarens filer under sin egna konto, tillhör samma grupp eller 'other'

Att man har "adminrättigheter" är ungefär samma sak som att du tillåts använda 'sudo' för olika kommandon som behöver vara root för att utföras.

Men det är inget som sker automagiskt för att man kör sftp utan du är då användaren med dess rättigheter - inte "root" rättigheter.

Förmodligen så behöver du ändra ägarskap och rättigheter på de filer du hittills har lagt in som 'root' för att de skall vara åtkomliga som användare. Det gäller också mappar och tex. åtkomst av monterade lagringar.

"chown" är bra kommando för att byta ägare och group för filer och "chmod" för att ändra filrättigheter som att skriva/läsa och exekvera/dyka ned i mappar - och de kan köra rekursivt ned i filträden för att byta alla filers ägandeskap och rättigheter i ett svep.

tänker du har passwordsfri inloggning för att komma åt filerna i en automatiserad process (script) så får du skapa och installera open-ssh nycklar där den publika delen skall sättas i servern och på användarens ~/.ssh mapp i filen "authorized_keys"

en av många i beskrivning att skapa SSH-nycklar och installation:

https://www.digitalocean.com/community/tutorials/how-to-confi...

Du får nog svara på Phods fråga om vad det är för ändringar du gjort utöver guiden du länkat.

Om användaren som kör sshd har exekveringsrättigheter (via ägarskap eller grupp) på sftpuser-hem-katalogen och sftpuser har rwx-rättigheter i uppladdningsmappen så bör det rimligen fungera.

Det finns en hel del du kan göra för att frågan ska bli tydligare. Använd ps för att visa vem som kör sshd. Använd ls för att visa vem som har rättigheter på katalogstrukturen. Visa felmeddelandet/loggen du får när du laddar upp en fil.

wheel används oftast med sudo, som du i så fall behöver använda. Men det beror såklart på hur din distribution har satt upp det som default och på vilka ändringar du gjort.

PermintNoRoot= no.

Är fel, det ska heta
PermitRootLogin no

Och inget annat.

Gruppen wheel ger bara behörighet att använda kommandot sudo, den gör dig inte till samma sak som root.

Kör kommandot
ls -la

I hemkatalogen för user2 och klistra in resultatet här, 99% att du gjort fel med rättigheterna, utifrån problemen du beskriver.

Man skall vara rätt kinkig med olika användares rättigheter om man skall börja med ACL-delen liknande ala windows i Unix-OS

Det fins en anledning varför man kör UGO-bitmask, user-id och group-id redan i metadatat för filen ifråga, och det gäller även olika processer/program eftersom i Unix-världen så är allt filer - även när du allokerar minne på RAM mellan interna processer så är det en UGO-bitmask, uid,gid som bestämmer om du får göra det eller inte.

Vad är vitsen med detta - jo det går skitsnabbt och utan speciellt mycket CPU-tid att slå upp saker för att veta om en användare får hantera filen eller inte utan att köra igenom en konstant växande ACL-databas som windows gör varav registret är en del av detta.

Man skall ha väldigt komplexa rättighetsmatriser (läs krångliga av typen som bara säkerhetsknarkare kan sätta upp) för användare innan man tycker/tvingas till ACL-rättigheter i Linux - men ibland kan det följa med ACL-poster via samba från windowsvärlden och då får man irriterande saker att inte ens root kan radera filer utan att fippla med ACL-delen för filen i fråga.