Ich habe schon ein paar Projekte mit ATmega und ENC28J60 realisiert. Nun muss ich fuer ein Studienprojekt einen SSH-Server sowie TLS auf einem Mikrocontroller (vorgabe vom Prof) realisieren, bin dabei aber ein wenig skeptisch. Mit einem ATmega duerfte das nicht zu stemmen sein. Daher wuerde ich jetzt einen AVR32 in Betracht ziehen (AT32UC3A)... OS (Linux) soll keins drauf laufen. Das soll alles selbst entwickelt werden. Was meint ihr? Hat vielleicht schonmal wer einen SSH-Server auf einem uC implementiert?
Macht das wirklich Sinn? Erstmal würde ich prophezeien, daß der Aufwand nicht unerheblich ist (weil ssh selbst ja wieder Ansprüche stellt), aber sicher machbar. Aber angenommen, man bekommt die ssh-Seite hin: was dann? Jemand macht eine Verbindung zu dem Rechner und findet - nichts. Irgendwoher muß ja noch ein Kommandointerpreter kommen, der auch etwas sinnvolles tut nach dem Verbindungsaufbau, und ein Dateisystem, wenn man mit scp etwas hin- und herkopieren will. Irgendwie erscheint mir das ohne OS dahinter nicht ganz schlüssig.
Natuerlich geht es ohne OS, aber die Kommunikationsfunktionalitaet muss trotzdem da sein. Da laeuft eine Menge bis der erste Block der SSH Kommunikation kommt. Es kann durchaus Sinn machen ohne OS auskommen zu wollen. Der Controller ist ein ganzes Stueck kleiner. Das kleinste Linux, das mir bekannt ist benoetigt um die 32MByte. Wenn man nur SSH will, zB fuer ein Kreditkartenterminal wird man wahrscheinlich mit unter 1MByte durchkommen.
Was aber noch nicht klärt, wozu man einen ssh-Dämon braucht. Alleine die Verschlüsselung einer Kommunikation geht mit weniger Aufwand. ssh ist Verschlüsselung + eine Shell. Wenn es letztere gar nicht gibt, macht ssh keinen Sinn.
Na dann schreibste dir in 100 Zeilen ne Shell die nicht ausser Hello World bei jeder Eingabe macht -> SSH tut genauso :)
Ja es soll eine Art Shell geben, die zur Konfiguration und Wartung dienen soll. Ob das jetzt so Sinn ergibt oder nicht, steht ersteinmal nicht zur Debatte. Das ist Vorgabe vom Prof und nur diskutabel, wenn es nicht machbar ist (oder den Zeitrahmen von rund 10 Monaten mit 6 Wochenstunden sprengen wuerde). Der Mikrocontroller verarbeitet potentiell personenbezogene Daten. Da der Controller auch ueber das Internet kommunizieren soll (ohne Hilfsmittel wie etwa einem zus. VPN-Router), muss eine Verschluessellung her. Hier ist die Vorgabe, es sollen Protokolle verwendet werden, die mit der Standardsoftware auf jedem PC zu benutzen sind (mit jedem PC meint der Prof Rechner mit Unix-artigem BS; Windows-Maschinen bezeichnet er als "Spielzeug"). Das Kommunikationsprotokoll, ueber welches der Controller mit dem Verarbeitungsserver spricht, ist eine Eigenentwicklung vom Prof. Das soll mit TLS verschluesselt werden. Bei der Auswahl vom Controllertyp habe ich relativ freie Wahl. Wichtig ist, dass das fertige Geraet moeglichst klein wird (Controller ohne externen Speicher).
Du kannst ja einen Vorversuch ohne µC machen. Schnapp dir "Dropbear", der ist recht klein, modular und portabel, und schau nach was du an Änderungen brauchst um den mit avr32-gcc oder arm-gcc o.Ä, zu kompilieren. http://matt.ucc.asn.au/dropbear/dropbear.html
Popdog schrieb: > Bei der Auswahl vom Controllertyp habe ich relativ freie Wahl. Wichtig > ist, dass das fertige Geraet moeglichst klein wird (Controller ohne > externen Speicher). Such dir auf jedenfall einen, der im Notfall auch Linux laufen lassen könnte. Wenn dann die Deadline immer näher rückt, hättest du zumindest einen Fallback-Plan um das Projekt doch noch zu retten.
>Das Kommunikationsprotokoll, ueber welches der Controller mit dem >Verarbeitungsserver spricht, ist eine Eigenentwicklung vom Prof. Das >soll mit TLS verschluesselt werden. Vermutlich wird wegen TLS die openssl Library benutzt. Da koennte es speichergroessenguenstiger sein, openssh (baut auf openssl auf) zu nehmen. VG, Hans
Hi, Generell gilt daß SSH wesentlich mehr macht als nur eine verschlüsselte Verbindung herzustellen und zu authentifizieren. Bei SSH hast Du z.B. noch TCP-Forwarding, SCP, .... TLS dagegen authentifiziert Dir Deine Verbindung und stellt Dir dann ein verschlüsseltes Socket zur Verfügung. Theoretisch gehen noch so Dinge wie nachträglich die Authentifizierung nochmal zu verändern. Das wird aber in der Praxis nicht genutzt und daher kannst Du auch gut drauf verzichten. Daher würde ich sagen daß eine Implementation von TLS einfacher sein sollte als eine von SSH. Auf einem richtigen OS (keinem Spielzeug ;-) kannst Du z.B. mit socat ganz locker eine TLS-verschlüsselte telnet-Sitzung aufmachen und so auf Deine Shell kommen. Natürlich ist man als User eher SSH gewohnt und dort ist das mit den Zertifikaten auch einfacher gehandhabt als bei TLS. Aber das TLS musste "nur" einmal machen und darüber kannst Du dann sowohl das komische Protokoll von Deinem Prof als auch die Shell abwickeln. Auch z.B. ein kleiner SSL-Webserver wäre dann schnell gemacht. SSH baut übrigens nicht auf SSL auf, sondern das openssh verwendet nur einige Crypto-Funktionen der openssl-Library für die Implementation. Schau Dir mal einen der freien TCP/IP-Stacks wie z.B. lwip an. Darauf könntest Du aufbauen. Vielleicht kannst Du Dich ja mit den Entwicklern abstimmen so daß das ganze als Erweiterung mit aufgenommen werden kann. Davon würden dann einige Projekte profitieren. Gruß, Gerd
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.