358 replies to this topic

[Erik Slagter]

Maar ja, verwacht niet dat ssh ooit in de windows tooltjes terecht komt.

Wat bedoel je daarmee?

 

En inderdaad, ik heb ook enige tijd gezocht naar een "null" cipher.

[mirakels]

Er is al een ssh zonder encryptie. Dat heet telnet.

Er is ook een scp zonder encryptie. Dat heet ftp of rsync.

 

Maar als je bang bent voor throughput en cpu cycles kan je ook tijd steken in het schrijven van een alternatief voor TCP/IP zodat je zo min mogelijk netwerk protocol overhead hebt.

[Erik Slagter]

Dat is wel erg cynisch. Telnet is niet echt bepaald hetzelfde als ssh.

 

Over hoe geweldig ftp bedacht is hebben we het al eens gehad en rsync is enorme overkill als je alleen even 1 file hoeft over te halen.

 

Verschil in cycles tussen null cipher en aes in software is op een stb, ehhh, "aanmerkelijk".

[christophecvr]

Hallo ter info voor binenshuis is ftp (of toch die van vsftpd) ideaal daar het niet gecripteerd is en zo inderdaad als milo zei de cpu niet onnodig belast. Bovendien zijn de prestaties voor midelgrote tot grote files super met ftp eigenlijk gebruiken deze de maximale in functie van je netwerk zelf en natuurlijk de devices speeds (bus speeds pc en box) . je haalt met ftp echt het maximum.

 

De commando's zijn echter wel belangrijk.

 

Voor een windows kan je fillezilla gebruiken die is vrij beschikbaar. Met linux pc gebruik ik gftp als client. Ok oud maar werkt zeer goed.

 

Nu weet ik niet wat hij doet met bestandsrechten als je backuped naar een windows pc , Ik vrees dat deze dan ook ,weg zijn. Dan is het best van eerst een archive tarbal te maken. op je box. Maar met linux pc vsftpd op box gftp als client kan je perfect backupen rechtstreeks met behoud van bestandsrechten. Dit maakt het leven aangenaam het enig probleem dan nog zijn de link's. Indien je deze wilt behouden als link dien je jammer genoeg alsnog een tar.gz te maken. Als ik een full image wil backuppen doe ik dat dan ook zo. Maar voor enkele bestanden is het verdomd eenvoudig met gftp.

 

De samba heb ik er uit geknikkerd bij mij heb dan toch geen windows en deze heeft geen passwoord protectie.

 

Voor streaming gebruik ik dan weer nfs.

 

Extern heb ik geen acces nodig naar mijn box en dat is dan ook zo niet ingesteld.

 

Maar als je het doet gebruik dan ssh zoals milo zegt. Will je de webif gebruiken doe dit dan ook met https en zie dat je een zéér zéér sterk passwoord hebt. (vergeet niet dat je box als root werkt en je acces dan ook super user is wat niet echt aan te raden is extern). Als je het dan doet verander ook je login.defs en zet SHA256 i.p.v de default DES en max len meer dan 12 characters. Dan is het gebruik van langere paswoorden dan 8 ok.

[mirakels]

Sorry Erik, maar als het om terminal emulatie gaat, wat is er zo verschrikkelik verschillend tussen telnet en ssh?

Het enige wat ik me kan bedenken is dat met PKi kan zorgen dat je op je client je private key gebruikt om direct (zonder manueel wachtwoord) in te loggen. Ik heb gewoon geen wachtwoord op root staan dus het is "telnet box <enter> <enter>" en ik ben binnen.

 

Wat ftp betreft snap ik niet wat je probleem is. Kijk eens naar ncftp en ncftpput en ncftpget:    "ncftpput -u root box remote_dir  local_file <enter> <enter>"

en de local_file staat op de box.

en voor "ncftpput -u root box remote" maak je natuurlijk een aliasje.

 

Oh, hoe dat op windows allemaal moet weet ik niet want dat gebruik ik niet.

[majz]

Since updating openpli34 to latest version I cannot connect to my et9000 with DCC it was working prior to version

OpenPLi-4.0-beta-et9x00-20130903_usb.zip 2013/09/03 05:13 - 46.58MB

[MiLo]

Sorry Erik, maar als het om terminal emulatie gaat, wat is er zo verschrikkelik verschillend tussen telnet en ssh?

Om er een paar te noemen:

1. Wederzijdse authenticatie.

Zelfde als HTTP versus HTTPS.
Telnet vraagt om een password. Als gebruiker is het niet mogelijk om na te gaan of de server wel is wie hij zegt dat hij is, dus weet je niet of je je passwoord wel aan de server kunt verstrekken. Als je een SSH sessie start, moet de server een challenge-response doen, en zo bewijzen dat hij echt de server is die hij zegt dat hij is. Als de server blijkt te jokken, ben je op tijd gewaarschuwd.

2. Shell protocol

Bestandoverdracht via telnet is technisch wel mogelijk (ik gebruik er wel eens een scriptje voor) maar werkt belabberd. Via SSH kun je pipes gebruiken (output van PC naar process op box sturen of andersom) en zo dus makkelijk data uitwisselen.

3. Bestandsoverdracht

SSH heeft een ingebouwd protocol voor bestandsoverdracht, "scp".

4. Tunneling

Via de SSH connectie kunnen willekeurige andere connecties worden getunneld.

[MiLo]

Het idee achter ssh zonder encryptie is dat je wel gebruik wil maken van bovenstaande punten (vooral punt 1), maar dat je niet zoveel belang hecht aan de data. Dus inloggen en gebruik van resources op de box wil je beperken, maar vervolgens heb je eigenlijk geen behoefte aan het beschermen van de data, want wat kan jou het boeien als iemand kan zien dat je een film van je box downloadt.

[mirakels]

Milo, we hebben het over 'thuisnetwerk'. Over wat beschreven werd heb je niet echt tunneling en wederzijdse auth nodig.

En het ging erom dat de ssh overhead zoveel resources op de stb box kost.

 

Natuurlijk snap ik wat ssh etc te bieden heeft. Op mijn werk draait het daar allemaal om.

[MiLo]

Maar ja, verwacht niet dat ssh ooit in de windows tooltjes terecht komt.

Wat bedoel je daarmee?

Dat ik niet verwacht dat SSH ooit gebruikt gaat worden in bijvoorbeeld dreamboxedit, ook al zou dat een uitstekende combinatie zijn.

[MiLo]

Milo, we hebben het over 'thuisnetwerk'. Over wat beschreven werd heb je niet echt tunneling en wederzijdse auth nodig.

Dus (3) bestandoverdracht is thuis niet handig? En aan een (2) pipe constructie heb je thuis ook helemaal niks?

Ik vind die punten alleen al genoeg om het gebruik te rechtvaardigen. Maar ik kan er nog wel meer aandragen:

5. Status reporting

Met een telnet verbinding kun je wel een remote commando runnen, maar je kunt niet simpel vaststellen of het commando ook geslaagd is omdat de return code niet terug komt. Je kunt niet eens betrouwbaar vaststellen of het commando al klaar is. Dus moet je de output gaan parsen, of nog een "echo $?" sturen en het resultaat daarvan parsen.

6. Een protocol "to rule them all"

Telnet voor commando's, FTP voor files, allemaal losse socket verbindingen. En prutswerk om het aaneen te knopen.
Je kunt ook een enkele ssh verbinding gebruiken om alles mee te doen. Files bewerken, data overdragen, sub-processen starten en beheren, noem het maar op. Het zit allemaal in de SSH API. Veel betere error afhandeling en geen gedoe met parsen van allerlei text-output, want dat loopt toch altijd mis, vandaar ook het gedoe nu met FTP.

Dat je thuis niet hoeft te encrypten, dat heb ik zelfs zelf hier nog geschreven. Maar dat wil niet zeggen dat het dan maar meteen helemaal nutteloos is.

Edited by MiLo, 6 September 2013 - 11:04.

[Erik Slagter]

@MiLo

 

Ah. Nee helaas inderdaad. "Te ingewikkeld".

 

Het mooie aan ssh is dat scp niet veel meer is dan aan beide kanten de executable scp opstarten en die gaat dan vrolijk over z'n ssh data channel met elkaar praten, briljant. Met telnet zou je zoiets nooit werkend kunnen krijgen. Al is het alleen maar omdat je met telnet niet automatisch kunt inloggen. En please niet over expect-scripts beginnen

 

Ook wellicht bekend met sftp? Dat is ftp zoals het geweest had moeten zijn. Net zo makkelijk met een ssh data channel.

Edited by Erik Slagter, 6 September 2013 - 11:05.

[Erik Slagter]

De mogelijkheden met ssh zijn schier oneindig. Ik heb ooit vroeger nog eens een ip-verbinding gemaakt tussen twee machines waartussen alleen http beschikbaar was, door pppd over ssh te tunnelen

[MiLo]

Dan weet ik nog een leuke: Veel bedrijven staan wel DNS verkeer toe door de firewall heen. Door "buiten" een server te draaien die daarop reageert kun je in de "reserved" bytes van de DNS pakketten een extra payload meesturen. Daarmee heb je dan ook weer een tunneltje gemaakt waarop je weer een verbinding kunt opzetten (beroerde bandbreedte, maar prototype toonde aan dat 't kon).

[christophecvr]

@MiLo

 

Ah. Nee helaas inderdaad. "Te ingewikkeld".

 

Het mooie aan ssh is dat scp niet veel meer is dan aan beide kanten de executable scp opstarten en die gaat dan vrolijk over z'n ssh data channel met elkaar praten, briljant. Met telnet zou je zoiets nooit werkend kunnen krijgen. Al is het alleen maar omdat je met telnet niet automatisch kunt inloggen. En please niet over expect-scripts beginnen

 

Ook wellicht bekend met sftp? Dat is ftp zoals het geweest had moeten zijn. Net zo makkelijk met een ssh data channel.

Sftp werkt uitstekend op de dreambox ook hoor.

 

opkg install openssh-sftp-server

 

En je hebt de server module. Deze maakt gebruik van dropbear , dus moet je niet de volledige ssh installeren.

 

Op pli 4 dien je jammer genoeg wel één extra aktie te doen, namelijk de sftp-server module dient in map /usr/libexec  te staan. Dus telnet of ssh je box opnieuw indien je reeds was uitgelogd. Dan gaan we een  linkje leggen naar de sftp-server module

 

cd /usr

mkdir libexec

cd libexec

ln -s /usr/lib/openssh/sftp-server sftp-server

 

Nu kan je verbinden met fillezilla sftp off ssh van gftp en ook ssh met nautilus.

Edited by christophecvr, 6 September 2013 - 11:16.

[Erik Slagter]

Sftp werkt uitstekend op de dreambox ook hoor.

Ongetwijfeld, nu nog al die gebruikers en ontwikkelaars zien te overtuigen. Ik heb geen sftp nodig, ik gebruik NFS.

[Erik Slagter]

Dan weet ik nog een leuke: Veel bedrijven staan wel DNS verkeer toe door de firewall heen. Door "buiten" een server te draaien die daarop reageert kun je in de "reserved" bytes van de DNS pakketten een extra payload meesturen. Daarmee heb je dan ook weer een tunneltje gemaakt waarop je weer een verbinding kunt opzetten (beroerde bandbreedte, maar prototype toonde aan dat 't kon).

Ik heb ook al gehoord van ip-over-icmp (een eitje, als je erover nadenkt, met z'n random payload bij icmp-echo) en zelfs ip-over-smtp (moet je wel geduld hebben).
 
Er is zelfs een RFC voor ip-over-postduiven.
 
En ach, als je eerste ervaring met "echte" computers was een microvax met 40 gebruikers er op (zoals in mijn geval) dan heb je geleerd met aardig wat lag te kunnen werken

Edited by Erik Slagter, 6 September 2013 - 11:18.

[christophecvr]

Sftp werkt uitstekend op de dreambox ook hoor.

Ongetwijfeld, nu nog al die gebruikers en ontwikkelaars zien te overtuigen. Ik heb geen sftp nodig, ik gebruik NFS.

 

NFS gebruik ik ook maar dan voor te streamen meer bepaals dvd.iso files te streamen naar mijn dreambox gaat zeer goed. Ik heb all mijn dvd's op pc gezet in iso (origineel formaat) . Je wordt er alleen lui van.

Ook is NFS ideaal om opnames te streamen naar pc . dan kan je jezelf een hd in box besparen wat beter is voor temperatuur zelf heb ik een hekel aan ventilators en vermijd deze zo veel mogelijk als het even kan. En als ik er dan gebruik deze van mijn pc zelf wat één zéér grote is die je nauwelijks hoort en ver van de leef kamer staat.   

 

Maar ik zet geen NFS server op mijn box zelf. Eigenlijk vermijd ik zoveel mogelijk de servers op de box door zijn gelimiteerde cpu ram en flash. Deze gebruik ik het liefst 100 % optimaal voor zijn uiteindelijke doel , namelijk mooie HD beeldjes en klank op mijn TV. En dan lekker lui kijken (voorzover ik niet in slaap val )

[Erik Slagter]

Ik heb geen harddisks in de ontvangers, dat gaat allemaal met NFS direct naar de server. En dan valt er dus eigenlijk niks meer te ftp'en of wat dan ook.

[christophecvr]

Ik heb geen harddisks in de ontvangers, dat gaat allemaal met NFS direct naar de server. En dan valt er dus eigenlijk niks meer te ftp'en of wat dan ook.

Dat is zo maar voor testen uitproberen backupen nazien wel. En de ftp is een echt zéér weinig flash en of ram vretend protocol dus ideaal voor transfers bovendien heeft het zéér goede performances . Op zich niet verwonderlijk daar het uit de tijd dateert dat voor 1 MB off memory je bijna rockefeller moest zijn. Eigenlijk is diegene die de ftp in busybox heeft ingebracht in de fout gegaan door deze nu weerom echt te beperkt te maken. (Ik vermoed een windows freak deze hebben de neiging bestandsrechten te vergeten en schijnen het belang ervan niet te bevatten). Uiteraard gaan we ftp enkel nog lokaal binnen beveiligde omgeving gebruiken. Alternatief is sftp extern dan wat zéér goed werkt. Wat uiteraard ook intern kan worden gebruikt.

 

De ftp maakt normaal gebruik van de basis users en paswoorden in linux. Waarom in openpli3 het werkt zonder passwoord en in pli4 niet weet ik niet. De makers van openembedded zullen wel iets over het hoofd gezien hebben met de compilatie ervan , Of misschien vereist de laatste vsftp die daarbij gebruikt word nu een standaard passwoord en kan een user zonder passwoord er niet meer voor gebruikt worden.