30.05.2018

6678

Raspbian Autologin via serieller Konsole verhindern

Hallo!

Ich habe auf meinem Raspi gemäß dieser Anleitung eine Möglichkeit geschaffen, mich mit dem Raspi via Bluetooth zu verbinden. Das klappt auch wunderbar mit meinem Windows 10 Laptop. Im Gerätemanager wird dann auch eine serielle Schnittstelle für diese Verbindung angezeigt (in dem Fall COM6). Wenn ich nun allerdings Putty hernehme und mich mit COM6@115200Baud verbinde, saust die Konsole mit einem Autologin für den User "pi" durch. Ich habe dann tatsächlich ohne weitere Passwortabfrage Rootzugriff. Das soll so natürlich keinesfalls sein. Wie kann ich also das Autologin für serielle Verbindungen verhindern?

PS: Bitte bedenken, ich bin kein Linux-Guru. Auf einer Skala von 0 bis 10 vielleicht eine 4 oder 5

Grüße
Cody

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 375407

Url: https://administrator.de/forum/raspbian-autologin-via-serieller-konsole-verhindern-375407.html

Ausgedruckt am: 22.12.2024 um 02:12 Uhr

26 Kommentare

Neuester Kommentar

Moin,

~~setze einfach ein Paßwort mit passwd!~~

lks

PS: Du solltest dann auch gleich das autologin in /etc/lightdm/lightdm.conf deaktivieren.

PPS: Ich habe mir gerade das Skript aus der Anleitung angesehen. Warst wohl zu faul, um die Befehle darin mal anzuschauen und die manpages dazu zu lesen. Du mußt einfach nur den Parameter -a pi von getty entfernen. Mein Rat: Wenn Du einfach Skripte aus dem Internet verwendest, ohne diese zu vestehen, wirst Du eines Tages ganz bös auf die Nase fallen und Deine ganzen Daten verlieren.

P3S:

Auf einer Skala von 0 bis 10 vielleicht eine 4 oder 5

eher 0 oder 1

Du solltest Dich etwas besser mit linux beschäftigen. Seit letztem Jahr scheint nicht viel Wissen dazugekommen zu sein.

Es reicht vermutlich auch das RasPi Konf Script raspi-conf aufzurufen und dort einfach das Autologin abzuschalten...

Zitat von @aqui:

Es reicht vermutlich auch das RasPi Konf Script raspi-conf aufzurufen und dort einfach das Autologin abzuschalten...

Nee, nicht in diesem Fall, weil das autologin in dem aufruf von getty durch rfcomm steckt. Sieh Dir einfach mal das Skript /home/pi/btserial.sh in der oben verlinkten Anleitung an, daß der TO benutzt hat, ohne es zu verstehen.

lks

Stimmt, du hast recht.
Da reicht es dann in der Tat einfach nur das -a pi zu entfernen.
-a steht vermutlich für "autologin" und pi ist der User pi. Bekommt man vermutlich auch so hin wenn man einen neuen User anlegt und den in die /etc/sudoers übernimmt und den pi User löscht. Ist aber umständlicher...

Danke für die "freundlichen" Antworten zu dem Thema. Das "-a pi" hatte ich schon gar nicht übernommen, nur beim Verfassen des Posts vergessen zu erwähnen. Geändert hat dies am Problem jedoch gar nichts. Auch nicht nachdem ich dieses Script nach einem Reboot neu aufgerufen habe. Auch das Abschalten vom Autologin via raspi-config bewirkt hier leider nichts.

Zitat von @Codehunter:

Danke für die "freundlichen" Antworten zu dem Thema.

das liegt aber nur daran, daß Du unvollständige Informationen lieferst und den Eindruck erweckst, daß Du manche Sachen gar nciht erst angeschaut hast.

Das "-a pi" hatte ich schon gar nicht übernommen, nur beim Verfassen des Posts vergessen zu erwähnen.

Sowas ist aber wesentlich.

Geändert hat dies am Problem jedoch gar nichts. Auch nicht nachdem ich dieses Script nach einem Reboot neu aufgerufen habe. Auch das Abschalten vom Autologin via raspi-config bewirkt hier leider nichts.

Und hast Du einfach mal versucht via passwd ein (anderes) Passwort zu setzen? Und auch mal in die lightdm.conf reingeschaut?

lks

Vielleicht sollten wir uns alle mal eine Runde entspannen? Schau mal auf die Uhrzeit von meinem Erstpost, da war mein Akku dann schon relativ am Ende

Das -a pi war so offensichtlich, deswegen irgendwie unbewusst entfernt. Auch das Autologin via raspi-config ist ja bekannt. Dass aber beides keine Änderung bewirkt, irritiert mich dann schon. Das Passwort vom User pi ist auch schon geändert.

Eine lightdm.conf gibt es auf dem System nicht. Es handelt sich um ein Raspian lite ohne Desktop. Was auffällt sind einige Fehlermeldungen beim Console-Login, die nur erscheinen wenn ich mich via Bluetooth "einwähle":

Raspbian GNU/Linux 9 raspberrypi rfcomm0
raspberrypi login: pi (automatic login)

Letzte Anmeldung: Dienstag, den 29. Mai 2018, 23:28:54 UTC auf rfcomm0

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
-bash: Kann die Prozessgruppe des Terminals nicht setzen (442).: Unpassender IOCTL (I/O-Control) für das Gerät
-bash: Keine Job Steuerung in dieser Shell.
pi@raspberrypi:~$

Hast du den erforderlich Konfig File serial-agetty@ttyAMA0.service in systemd dafür angepasst indem du dort -a <username> entfernt hast ??
Siehe auch:
https://www.raspberrypi.org/forums/viewtopic.php?t=145134

@aqui: In /etc/systemd/system/getty.target.wants/getty@tty1.service sieht der Abschnitt Service wie folgt aus:

[Service]
# the VT is cleared by TTYVTDisallocate
ExecStart=-/sbin/agetty --noclear %I $TERM
Type=idle
Restart=always
RestartSec=0
UtmpIdentifier=%I

Da sehe ich also auch nix in Form von -a pi

Dann wäre /etc/securetty noch so ein Kandidat. Steht da was drin ??
Die sollte leer sein !

Moin,

ich würde einfach mal für testzwecke einen neuen User anlegen und den User pi deaktivieren (einfach in /etc/passwd auskommentieren). Dann sieht man, immer noch ein autologin durchgeführt wird. zumindest sollte dann in den Logs irgendwo ein Fehler auftauchen, das einen Hinweis auf den passenden Dienst und dessen Config geben könnte.

lks

Der user pi ist aber kein Root User !
Wenn er das macht sollte er den neuen User aber schlauerweise auch in die /etc/sudoers eintragen sonst sägt er sich den eigenen (root) Ast ab

Zitat von @aqui:

Der user pi ist aber kein Root User !
Wenn er das macht sollte er den neuen User aber schlauerweise auch in die /etc/sudoers eintragen sonst sägt er sich den eigenen (root) Ast ab

So viel Mitdenken erwarte ich schon von einen Fragesteller.
Ansonsten ist ein Pi recht schnell frisch installiert.

lks

PS: Man kan die SD-Karte natürlich auch offline wieder zurechtbiegen., falls etwas schiefgeht.

So... Ich konnte das Problem inzwischen lösen. Es lag doch tatsächlich an der /etc/systemd/system/rfcomm.service Datei. Da stand das -a pi drinnen. Nur hatte ich den seltsamen Effekt, dass ich diese Datei mit sudo nano so oft ändern konnte wie ich wollte, nano hat zwar so getan als würde er die Änderung speichern, tat es aber nicht. Das -a pi blieb drin stehen.

Ich habe dann eine Kopie der Datei erstellt, das Original gelöscht, die Kopie bearbeitet, den Raspi rebootet,die Kopie wieder in rfcomm.service umbenannt, nochmal rebootet, dann war der Fehler verschwunden. Danach hat sich nano beim Speichern auch ganz normal verhalten wenn ich die rfcomm.service anschließend bearbeitet habe.

Vorsichtshalber habe ich dann eine andere SD-Karte hergenommen, vielleicht hat die bisherige ein Problem. Die ist schon recht alt. Also habe ich das Raspian Lite nochmal komplett frisch aufgesetzt, alles ordentlich gemacht und das Gebastel vermieden. Jetzt läufts wie es sein soll, beim Konsolenlogin über Bluetooth wird das Passwort abgefragt.

Was auch immer da passiert ist, richtig erklären kann ich es mir nicht.

nano hat zwar so getan als würde er die Änderung speichern, tat es aber nicht.

Hast du wohl vergessen zuerst <ctrl o> zu drücken und dann erst <ctrl x>

Möglich auch das du keine Schreibrechte auf die Datei hattest aber das sagt dir nano dann beim <ctrl o> auch.
Entweder sudo su vorab eingeben oder sudo nano ...
Na ja egal, wenns nun geklappt hat ist ja alles gut ! Ich denke wir haben alle was gelernt

Muss ich auch gleich mal auf dem RasPi Zero probieren hier

Obwohl der Zugang über LAN oder WLAN einfacher ist.
Man kann sich auch sehr einfach mit shellinabox ein Tool für den Zugang via Webbrowser in Sekundenschnell installieren:
Netzwerk Management Server mit Raspberry Pi
Einfach Webbrowser starten mit http://raspberrypi.local:4200 et voila...schon ist man auf der Shell !
Na ja...gibt viele Wege nach Rom...

Bleibt ja dann nur noch
Wie kann ich einen Beitrag als gelöst markieren?

Der Grund warum ich das über Bluetooth gebaut habe ist ein rein praktischer. Der Raspi wird in ein IP66-Gehäuse eingebaut und soll sich am Einsatzort per WLAN verbinden. Damit ich dort nicht noch mal alles aufschrauben und ein LAN-Kabel anstecken muss um ihn ins WLAN zu bringen, verwende ich die Lösung über Bluetooth. Eine reine Wartungsschnittstelle, die natürlich nicht offen stehen soll wie ein Scheunentor.

In einer zweiten Evolutionsstufe baue ich dann noch einen mechanischen Schlüsselschalter ins Gehäuse an den GPIO und schalte darüber Bluetooth ein oder aus.

Bzgl. nano: Keine Schreibrechte kanns eig. nicht gewesen sein. Ich hatte die Datei ja schon mehrmals vorher geändert und da wurde es übernommen. Hätte ich das sudo vor dem nano vergessen, dann hätte es eine Fehlermeldung beim Speichern gegeben.

Bei WLAN hättest du ja dann auch normal über SSH oder eben shellinabox Zugang. Wäre ja noch einfacher

Oder hast du aus Sicherheitsgründen auch den SSH Server gestoppt. Dann bleibt dir natürlich nur Bluetooth.
Die Lösung ist aber pfiffig um den RasPi zu managen. Gerade wenn man das noch mit einem Schlüsselschalter deaktivieren und aktivieren kann.

Um ehrlich zu sein habe ich es nie hinbekommen, dass ein Raspi gleichzeitig ein WLAN-AP ist oder ein Ad-Hoc-Netz anbietet und zusätzlich auch noch Client in einem vorhandenen WLAN ist. Andernfalls hätte man in dem Szenario ein Henne und Ei Problem: Ohne Konsole bekäme man ihn nicht ins WLAN, ohne bestehende WLAN-Verbindung keine SSH-Konsole.

Insofern ist die Bluetooth-Lösung eleganter - wenn man erst mal rausgefunden hat wie

Noch schicker wäre sicherlich eine Hardware-Schnittstelle zur Wartung, was allerdings in puncto IP66 und Dichtigkeit nicht ganz einfach bzw. günstig zu realisieren ist.

SSH war hier nie aktiviert. In der Bastelphase hatte ich eine USB-Tastatur und Monitor direkt dran. Wenn ich so darüber nachdenke war das verlinkte Script im Erstpost nicht besonders clever gemacht. Autologin über rfcomm in ein Tutorial zu schreiben. Da kann die Bank auch gleich die Geldsäcke über Nacht im Hinterhof lagern. Ihr habt ja auch gedacht, ich hätte das unreflektiert einfach übernommen. Manch einer wird das bestimmt sogar machen.

Insgesamt ist das schon interessant, sich mit IoT im praktischen Einsatz abseits vom Schreibtisch zu befassen. Da steht man dann auch vor Fragen wie z.B. man das Auto-Update von Software realisieren kann, so dass es auch regelmäßig und langfristig ohne manuelles Eingreifen funktioniert.

Zitat von @aqui:

Na ja egal, wenns nun geklappt hat ist ja alles gut ! Ich denke wir haben alle was gelernt

Jupp, war interessant, wo überall ein autologin stecken kann. ich kannte da auch nciht alle Varianten.

lks

Zitat von @Codehunter:

SSH war hier nie aktiviert. In der Bastelphase hatte ich eine USB-Tastatur und Monitor direkt dran. Wenn ich so darüber nachdenke war das verlinkte Script im Erstpost nicht besonders clever gemacht. Autologin über rfcomm in ein Tutorial zu schreiben. Da kann die Bank auch gleich die Geldsäcke über Nacht im Hinterhof lagern. Ihr habt ja auch gedacht, ich hätte das unreflektiert einfach übernommen. Manch einer wird das bestimmt sogar machen.

An Dich nochmal mein aufrichtige Entschuldigung. Aber Du hast mit Deine Frage ohne weitere Infos, was Du schon versucht hast den Eindruck erweckt, Du hättest einfach mal auf die schnelle das Skript reingepfriemelt ohne weiter darüber nachzudenken. Und mit dem Artikel vom letzten Jahr im Hinterkopf, kam halt der Eindruck auf, daß Du Dir keine Mühe gibst, was jetzt sich als falsch herausstellt.Von daher also nochmal sorry für den entsprechenden Post.

Schönen Restfeiertag und ggf. überlanges Wochenende noch,

lks

dass ein Raspi gleichzeitig ein WLAN-AP ist oder ein Ad-Hoc-Netz anbietet

Das ist aber kinderleicht.
Ganz einfach wenn du 2 Adapter hast, also bei einem moderneren RasPi das eingebaute und dann z.B. ein nano WLAN USB Stick. Sonst 2 Sticks.
Dann lässt du ein Interface mit hostapd als AP rennen und das andere standardmässig als Client. Das ist in 5 Minuten erledigt.
Hier musst du nur gewaltig darauf aufpassen das du den hostapd mit einem mindestens 5 kanaligen Abstand zum Client Netzwerk startest.
Sonst stören sich die beiden auf der Funk Schnittstelle und nix geht mehr. Vermutlich war wohl das dein Fehler ?!
Hab ich hier schon mehrfach gemacht und rennt fehlerlos.

Noch schicker wäre sicherlich eine Hardware-Schnittstelle

Da kann man dann problemlos das serielle Terminal auf den GPIOs nehmen. Für eine simple 3 polige Niedervolt Buchse gibt es aber zig Optionen wo man da fündig wird. Die Steckerabteilung von Reichelt.de lässt grüßen

sich mit IoT im praktischen Einsatz abseits vom Schreibtisch zu befassen.

Vor allen Dingen IoT in puncto Sicherheit. Was viele der Professionellen ja scheinbar nicht oder zuwenig machen...

man das Auto-Update von Software realisieren kann

UMTS Stick in den RasPi stecken

Netzwerk Management Server mit Raspberry Pi

@aqui: Du hast natürlich recht. Zur Beantwortung möchte ich mich hier selbst zitieren:

Zitat von @Codehunter:

Insofern ist die Bluetooth-Lösung eleganter - wenn man erst mal rausgefunden hat wie

Noch schicker wäre sicherlich eine Hardware-Schnittstelle zur Wartung, was allerdings in puncto IP66 und Dichtigkeit nicht ganz einfach bzw. günstig zu realisieren ist.

Ein WLAN- oder UMTS-Dongle, wie auch mehrpolige Verbindungen nach IP66, hätten das Projekt nur verteuert. Wenn man derlei Dinge nicht zufällig rumliegen hat sondern bestellen muss kommen noch Versandkosten dazu und beim UMTS natürlich die SIM. Obendrein am Einsatzort kein 3G, 4G oder 5G Empfang verfügbar. Also mit dem was der Raspi von Haus aus an Bord hat wüsste ich jedenfalls keinen Weg, gleichzeitig in zwei WLANs verbunden zu sein. Vor einiger Zeit habe ich mal ein Proof of Concept gesehen, wonach man eine einzelne MIMO-WLAN-Schnittstelle so vergewaltigen konnte dass die einzelnen Transceiver als separate Interfaces ansprechbar waren. Die Performance lag aber auf dem Niveau von 802.11b.

Zitat von @Lochkartenstanzer:

An Dich nochmal mein aufrichtige Entschuldigung. Aber Du hast mit Deine Frage ohne weitere Infos, was Du schon versucht hast den Eindruck erweckt, Du hättest einfach mal auf die schnelle das Skript reingepfriemelt ohne weiter darüber nachzudenken. Und mit dem Artikel vom letzten Jahr im Hinterkopf, kam halt der Eindruck auf, daß Du Dir keine Mühe gibst, was jetzt sich als falsch herausstellt.Von daher also nochmal sorry für den entsprechenden Post.

Entschuldigung angenommen, wenn auch unnötig

Ich habe dir damals schon geschrieben, dass du das Ziel meines Experiments missverstanden hattest. Es ging genau um die Simulationen eines ungeduldigen Windows-Anwenders, der von einer OS-Installation einfach erwartet dass sie ohne Fallstricke durchläuft. Ich hätte ohne Weiteres jede der Distros zum Laufen bekommen können. Vielleicht könnte man auch so sagen: Als ein Fingerzeig in Richtung Failsafe- und Usability-Optimierung der Installer zu sehen. Oder anders ausgedrückt: Ich habe mich absichtlich DAU-mäßig angestellt

Nochmal zum Thema Autologin: Wenn man im Netz nach dem Problem sucht, findet man haufenweise Fragen und Lösungen, wie man das Autologin EINschalten könnte. Das zeigt auch ein wenig, wie die Userschaft das Thema Sicherheit sieht.

Kurzer Nachtrag:
Ich hab das heute aus Neugierde auch mal aktiviert sowohl auf einem RasPi2 mit Jessie und USB BT Adapter als auch einem Pi3B / Pi Zero/W mit integriertem BT und Stretch. Jeweils latest Patch.
Dabei stellte sich heraus das das o.a. Script gar nicht erforderlich ist !!!
Bei Jessie muss man natürlich mit apt-get install bluez bluez-tools noch den BT stack installieren.
Die manuelle Prozedur ist hier erklärt aber all diese Anpassungen sind im aktuellen Jessie und Stretch schon per Default enthalten wie sich rausstellt.
Sieht man sich dann den systemd BT service an der gestartet wird unter /etc/systemd/system/dbus-org.bluez.service :

[Unit]
Description=Bluetooth service
Documentation=man:bluetoothd(8)

[Service]
Type=dbus
BusName=org.bluez

ExecStart=/usr/lib/bluetooth/bluetoothd -C --noplugin=sap
ExecStartPost=/usr/bin/sdptool add SP
ExecStartPost=/bin/hciconfig hci0 up
ExecStartPost=/bin/hciconfig hci0 piscan

NotifyAccess=main
#WatchdogSec=10
#Restart=on-failure
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
LimitNPROC=1

[Install]
WantedBy=bluetooth.target
Alias=dbus-org.bluez.service 

Started der schon im Discoverable Mode. Wenn nicht kann man ihn dazu bringen unter bluetoothctl und dort mit dem Kommando discoverable on

~~Dann sieht man unter /etc/systemd/system/rfcomm.service auch einen systemd rfcomm Daemon:~~
Nicht mehr so in aktuellen Distros wie Bullseye oder Bookworm wo dieser Service im o.a. Verzeichnis manuell hinzugefügt werden muss.

[Unit]
Description=RFCOMM service
After=bluetooth.service
Requires=bluetooth.service

[Service]
ExecStart=/usr/bin/rfcomm watch hci0 1 setsid /sbin/agetty -L rfcomm0 115200 vt100

[Install]
WantedBy=multi-user.target 

Dieser startet also schon eine serielle Bluetooth Schnittstelle "by Default"

Mit dem Mac ist man da dann schnell drauf:
Raspberry discovern und verbinden (Hostname hier "lcdpi"):

Darauf hat man eine serielle Schnittstelle unter /dev Mit Namen cu.<hostname_raspi>-SerialPort

Mit zTerm connecten und BT Schnittstelle auswählen:

Oder auch ein screen /dev/cu.lcdpi-SerialPort 115200 im Terminalfenster...
Und schon ist man auf der RasPi Konsole

Das dürfte mit einem Winblows PC und PuTTY oder TeraTerm identisch sein.

Nachtrag...
Ein paar Tests mit neuen Raspberries egal ob Modell 2 mit Mini USB BT Stick oder Modell 3 oder Zero W zeigt, das in einer Default Installation von Rasbian Lite keine RFCOMM Konfig im Default vorhanden ist !
Man sollte also besser die beiden o.a. Konfig Dateien noch einmal genau überprüfen und ggf. anpassen wenn sie nicht so aussehen wie oben !
Die Datei /etc/systemd/system/dbus-org.bluez.service muss dazu zwingend die beiden Zeilen:
ExecStart=/usr/lib/bluetooth/bluetoothd -C --noplugin=sap
ExecStartPost=/usr/bin/sdptool add SP
enthalten !
Im Falle das die Datei /etc/systemd/system/rfcomm.service fehlt, ist diese nachträglich mit dem nano Editor anzulegen mit folgendem Inhalt:

[Unit]
Description=RFCOMM service
After=bluetooth.service
Requires=bluetooth.service

[Service]
ExecStart=/usr/bin/rfcomm watch hci0 1 setsid /sbin/agetty -L rfcomm0 115200 vt100

[Install]
WantedBy=multi-user.target 

Datei mit chmod 755 rfcomm.service ausführbar machen !!
Der Parameter -a gibt den Login Namen an, hier Default User "pi". Ggf muss der geändert werden sollte ein anderer Username zum Login verwendet werden.
Noch sicherer ist es allerdings wie oben im Thread auch die Lösung war das "-a pi" komplett wegzulassen, so bekommt man dann einen normalen Login Prompt für Username und Passwort !

Danach den RasPi mit shutdown -r now rebooten.
Nach dem Reboot Bluetooth auf Discovery Mode setzen mit Aufruf von bluetoothctl und dort mit dem Kommando discoverable on ! (Muss nur ein einziges Mal gemacht werden um die Geräte zusammenzubringen !)
Windows starten und Bluetooth Device hinzufügen mit "+". Dort erscheint dann der RasPi mit seinem Hostnamen:

Gleichzeitig sieht man das Windows unter Bluetooth Einstellungen automatisch 2 virtuelle, serielle COM Port Adapter angelegt hat.

Diese erscheinen dann, wie man oben sieht, auch im Geräte Manager ! Relevant ist hier der Adapter mit der Bezeichnung "Serial Port" !
Nun startet man PuTTY oder Teraterm (Windows) und stellt als serielle Schnittstelle diesen COM Port ein:

Die serielle Baudrate im Terminal Programm spielt dabei keine Rolle, da der Adapter sich automatisch anpasst. Sinnvoll ist ihn auf 115200 Baud zu setzen.

Hallo Aqui,

hab vielen Dank für deine ausführliche Antwort. Ich habe erst jetzt wieder Zeit gefunden für das Projekt. Du hast vollkommen Recht, das "-a pi" ist ein ziemlicher Quark aus sicherheitstechnischer Sicht. Den Rest habe ich soweit auch hinbekommen. Der Terminalserver vom Raspbian scheint aber ein paar eigenartige Marotten zu haben:

SCREEN sendet automatisch AT-Befehle via RFCOMM

Vermutlich hatte ich mangels Erfahrung viele der hier beschriebenen Probleme irrtümlich auf Seiten des Clients verortet.

Grüße
Cody

Sinnvoll ist es das mit einem SSH Login zu koppeln. Das klappt vollkommen fehlerfrei und ist zudem noch sicher.
Mal angenommen du hast in allen 4 Ports einen USB-Seriell Adapter stecken der auf serielle Endgeräte geht, dann sieht die Konfig so aus:

Mit "adduser" (Debian Ubuntu basierte Distros) 4 neue User mit useradd serialx anlegen !
Jetzt legst du in /usr/local/bin 4 Shellscripte an und machst sie ausführbar mit folgendem Inhalt:
#!/bin/sh /usr/bin/telnet 127.0.0.1 2001 exit

Wobei du mit jedem User die Portnummer hinten "2001" erhöhst. Script User 2 = 2002 usw.

Dann nagelst du das User Login in der Datei /etc/passwd auf dieses Script fest:

serial1:x:1001:1001:Seruser1,,,:/home/serial1:/usr/local/bin/serial_login1.sh
serial2:x:1002:1002:Seruser2,,,:/home/serial2:/usr/local/bin/serial_login2.sh
serial3:x:1003:1003:Seruser3,,,:/home/serial3:/usr/local/bin/serial_login3.sh
serial4:x:1004:1004:Seruser4,,,:/home/serial4:/usr/local/bin/serial_login4.sh 

Passt die ser2net.conf Konfig Datei entsprechend an:

BANNER:banner:\r\nWelcome to ser2net, TCP \p  Device \d  Serial \s\r\n
# 2000:telnet:600:/dev/ttyS0:9600 8DATABITS NONE 1STOPBIT banner
2001:telnet:600:/dev/ttyUSB0:9600 8DATABITS NONE 1STOPBIT banner
2002:telnet:600:/dev/ttyUSB1:9600 8DATABITS NONE 1STOPBIT banner
2003:telnet:600:/dev/ttyUSB2:9600 8DATABITS NONE 1STOPBIT banner
2004:telnet:600:/dev/ttyUSB3:9600 8DATABITS NONE 1STOPBIT banner 