[Linux - Unslung] SFTP met dropbear of openssh, alleen root

[!null]

Ik heb dus een Linksys NSLU2 met Unslung(6.10) erop, maar het zou wel eens een algemeen Linux iets kunnen zijn.
Ik heb op het systeempje meerdere gebruikers, naast het root account.

Wat wel lukt:
- inloggen over ssh en een shell voor je neus krijgen, root en andere users
- onbeveiligde ftp (vsftpd), root en andere users
- inloggen over SFTP -> ALLEEN root kan dit

En ik wil dus met de andere users ook met SFTP naar binnen kunnen, maar dan krijg ik simpelweg "SFTP Connection Error" (ik gebruik daarvoor CoreFTP). Het is dus geen kwestie van foute login, want anders zou de error dat gewoon vertellen.

Ik heb het inmiddels geprobeerd met gewone openssh deamon, en ook met dropbear, geen verschil. Echter gebruiken ze allebei uiteindelijk gewoon de openssh-sftp-server package/app om een SFTP server te starten op aanvraag.

Edit, de gebruiker en z'n home directory zijn in orde. De gebruiker is ook owner van de home directory, en alle rechten zijn ook goed.

Hebben jullie ideeën?

[ Voor 7% gewijzigd door !null op 25-05-2008 15:22 ]

[Mr_gadget]

heb je de gebruikers ook als systeem user? Misschien moet je proberen ze aan de sudo'ers toe te voegen?

[!null]

Er is geen sudo aanwezig.
Hoe weet ik of een gebruiker lid is van de systeem users? Ik heb de gebruiker wel lid gemaakt van de groep 'users'.

[!null]

Ik heb het nu wel op een ontzettend smerige manier aan de praat trouwens. Dat moet toch wel netter kunnen. Ik heb de UID in /etc/passwd veranderd naar 0 <- de UID van root. Dan logt ie wel in met alle data van de gebruiker (ook goeie home dir).
De gebruiker toevoegen aan de groep root maakt trouwens niet uit.

[BCC]

SFTP is gewoon FTP getunneld over SSH. Mag je als ingelogde SSH user wel lokaal met de FTP server verbinding maken?

[!null]

Hoe bedoel je? De gebruiker mag wel inloggen over ssh (met gewoon shell) en mag wel inloggen op gewone ftp. openssh-sftp-client kan ik blijkbaar niet installeren, om lokaal iets te proberen zoals jij misschien bedoelt.

Verder, denken jullie dat ik het probleem moet zoeken bij de openssh-sftp-server, of bij dropbear/sshd en de configuratie daarvan?

Ik zie ook nergens config files, moet ik niet ergens expliciet aangeven dat sftp voor betreffende gebruiker mag (waar ik dan misschien ook chroot aan kan geven?)

[ Voor 41% gewijzigd door !null op 25-05-2008 15:36 ]

[blaataaps]

BCC schreef op zondag 25 mei 2008 @ 15:30:
SFTP is gewoon FTP getunneld over SSH.

Dat is het niet.

[!null]

blaataaps schreef op zondag 25 mei 2008 @ 15:50:
[...]

Dat is het niet.

In zekere zin wel toch? Het werkt alleen anders, als in dat de ssh deamon de sftp-server runt op aanvraag, waar bij normale ftp er gewoon altijd een ftp deamon draait.

[blaataaps]

In zekere zin, alleen in de zin dat je er ook files mee transporteert, maar sftp is heel wat anders dan "ftp over een ssh tunnel", dat is het namelijk gewoon niet

[!null]

Ok, als ik daar even op zoek blijkt het idd een nieuw ontworpen protocol te zijn. Maar goed, daar heb ik op het moment niks aan

[BarthezZ]

Verbose logging (op zowel server als client) aangooien om te kijken welke error meldingen het outspuugt om te checken waarom het het sftp subproces niet kan/mag starten?

[!null]

Ik ben nu even aan het uitzoeken hoe ik extra kan loggen, maar hij logt default naar syslog kwam ik achter, en die zegt dus dit:

May 26 02:54:01 (none) authpriv.info dropbear[1134]: Child connection from 192.168.1.12:49742
May 26 02:54:08 (none) authpriv.notice dropbear[1134]: password auth succeeded for 'root' from 192.168.1.12:49742
May 26 02:55:01 (none) authpriv.info dropbear[1139]: Child connection from 192.168.1.12:49746
May 26 02:55:02 (none) authpriv.notice dropbear[1139]: password auth succeeded for 'gebruiker' from 192.168.1.12:49746
May 26 02:55:02 (none) authpriv.info dropbear[1139]: exit after auth (gebruiker): Disconnect received

Dus het gaat goed, net als bij het root account, alleen is er daarna een disconnect.. vaag..
Ik kan trouwens geen informatie vinden over de configuratie mogelijkheden in de dropbear config file. Daar staan maar 2 dingen in, er staat verder niks in uitgelegd.

Filezilla zegt trouwens niet veel nuttigers:
Fout: Fatal: unable to initialise SFTP on server: could not connect
Fout: Kan niet verbinden met server
Waar CoreFTP gewoon zegt 'SFTP Connection error'

[ Voor 18% gewijzigd door !null op 25-05-2008 20:53 ]

[!null]

Ik ben er nog niet achter hoe ik dropbear uitgebreider laat loggen, maar ook als ik em naar stderr laat loggen komt er hetzelfde uit:

[1292] May 26 03:52:14 Child connection from 192.168.1.12:50294
[1292] May 26 03:52:14 password auth succeeded for 'gebruiker' from 192.168.1.12:50294
[1292] May 26 03:52:14 exit after auth (gebruiker): Disconnect received
[1294] May 26 03:53:16 Child connection from 192.168.1.12:50297
[1294] May 26 03:53:21 password auth succeeded for 'gebruiker' from 192.168.1.12:50297
[1294] May 26 03:53:21 exit after auth (gebruiker): Exited normally
[1296] May 26 03:53:26 Child connection from 192.168.1.12:50299

Eerste is CoreFTP, tweede FileZilla.


Volgens mij kan het maar aan twee dingen liggen:
- een kwestie van in de juiste groep zitten
- een rechten kwestie op bepaalde bestanden (executables? libs?) die in het traject worden aangeroepen.

[ Voor 12% gewijzigd door !null op 25-05-2008 21:24 ]

[!null]

Opgelost!

Niet echt op een heel bevredigende manier, maar het werkt. Ik ging met beide gebruikers (root en die andere) gewoon handmatig vanaf de shell sftp-server executable starten om te kijken wat er zou gebeuren, op zoek naar een fout. Bij root gebeurde er (natuurlijk) niks, het programma wacht ook op input over stdin.
Maar toen ik het onder die andere gebruiker ging uitvoeren, kreeg ik direct de error dat ie niet naar /dev/null kon schrijven, permission error. Dus nu heb ik een chmod gedaan op /dev/null en nu werkt het, nu kan er gewoon ingelogd worden over sftp zonder problemen!

Ik zou nu alleen nog willen chrooten, dat zoek ik wel even uit.

[silentsnake]

GreenSky schreef op zondag 25 mei 2008 @ 15:58:
[...]


In zekere zin wel toch? Het werkt alleen anders, als in dat de ssh deamon de sftp-server runt op aanvraag, waar bij normale ftp er gewoon altijd een ftp deamon draait.

Nee, de enige overeenkomst is dat er FTP in allebei de namen staat. FTP gebruikt het FTP protocol, SFTP gebruikt het SSH protocol. Twee verschillende dingen dus.

Het lijkt op een permissie probleem in eerste instantie, aangezien je met root wel kan inloggen en met een normale user niet. Check eens de permissies op de home folders enzo? Je moet zeker read en execute rechten op een directory (755 is gebruikelijk), anders kan je er niet alles. Zonder execute rechten op een directory kan je geen ls geven, om maar een voorbeeld te geven. Aangezien root directory rechten kan omzeilen zou dit toch het meest voor de hand liggende zijn, hoewel je zou denken dat SSH zelf het dan ook niet zou doen.

_{Ah, je had de oplossing al gepost toen ik mijn post aan het tikken was}

[ Voor 4% gewijzigd door silentsnake op 25-05-2008 22:18 ]

[!null]

Zoals aangegeven waren de rechten voor de home directories allemaal in orde. Het lag uiteindelijk dus aan de rechten op /dev/null, welke blijkbaar gebruikt wordt door (openssh-)sftp-server

[!null]

Nu krijg ik de ChrootDirectory setting van de sshd config file niet aan de praat. Het lijkt zo simpel, gewoon een setting met als waarde de directory. Maar ik krijg deze error, wat ik ook proberen:

auth.crit sshd[736]: fatal: bad ownership or modes for chroot directory component "/"

Ook veel ge-experimenteer met rechten en ownership van de betreffende directory helpt niet.

[BarthezZ]

Gebruik even het dit knopje om je topic niet meerdere keren te schoppen

Over verbose logging. Je hebt het kennelijk al gevonden hoe je de daemon niet als daemon laat draaien (attached op een shell dus) meestal als je sshd --help (of -h of -? of iets dergelijks) krijg je help informatie te zien. vaak staat daar ook iets bij over verbose, vaak de -v switch. Meestal kan het "meer verbose" worden als je meerdere malen die switch gebruikt.

Ik ken de interne chroot functie van sshd-sftp-server niet. Wat ik daarvoor altijd heb gebruikt is een chrootsh om dat voor elkaar te krijgen.

[!null]

Je hebt gelijk, ik zou meer moeten edit-en.

Ik was op dat moment bezig met dropbear, en die kent weinig opties, helemaal geen wat betreft logging. Ik verwacht dat sshd idd wel die opties heeft, aangezien die wat uitgebreider is. En tja, dropbear is gewoon een executable, dus kun je vrolijk runnen. Hij laat het ook nog toe om naar stderr weg te schrijven ipv syslog.

[ Voor 23% gewijzigd door !null op 26-05-2008 10:17 ]

[!null]

Nu ben ik bezig met die ChrootDirectory setting in sshd_config, maar het wil niet. Ik krijg de hele tijd:
auth.crit sshd[1199]: fatal: bad ownership or modes for chroot directory component "/"

Stukje over die setting:

ChrootDirectory
Specifies a path to chroot(2) to after authentication. This
path, and all its components, must be root-owned directories that
are not writable by any other user or group.

The path may contain the following tokens that are expanded at
runtime once the connecting user has been authenticated: %% is
replaced by a literal '%', %h is replaced by the home directory
of the user being authenticated, and %u is replaced by the user-
name of that user.

The ChrootDirectory must contain the necessary files and directo-
ries to support the users' session. For an interactive session
this requires at least a shell, typically sh(1), and basic /dev
nodes such as null(4), zero(4), stdin(4), stdout(4), stderr(4),
arandom(4) and tty(4) devices. For file transfer sessions using
``sftp'', no additional configuration of the environment is nec-
essary if the in-process sftp server is used (see Subsystem for
details).

De betreffende map (en bovenliggende) zijn allemaal van root (als owner) maar toch blijf ik die fout krijgen. Iemand?

Edit: Zojuist gevonden: http://www.nslu2-linux.org/wiki/HowTo/ChrootJailForSFTP
Dit is wel heel omslachtig. Ik snap niet helemaal waarom die setting ChrootDirectory niet gewoon gebruikt kan worden? Het is allemaal 0.4.9, dus die setting moet gewoon werken.

[ Voor 7% gewijzigd door !null op 27-05-2008 23:27 ]