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.
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
