Standardmäßig versendet Postfix die Mails wie sie ankommen, also z.B. mit dem jeweiligen Nutzernamen als Absendeadresse. Nutzt man jedoch einen Smarthost, lässt ausgehende Mails also z.B. über den Server des Providers abwickeln, ist dies häufig nicht erlaubt, einzig die eigene E-Mail wird akzeptiert.
Mit diesen Schritten kann man Postfix anweisen alle ausgehenden Mails so umzuschreiben, dass die vorgegebene E-Mail-Adresse als Absender genutzt wird. Da so auch nicht mehr auf den ersten Blick ersichtlich ist wer die Mail versendet hat, eignen sich diese Schritte nur für Systeme, auf denen ausschließlich vertrauenswürdige Personen Zugang gewährt wurde. Weiterhin gehe ich davon aus, dass Postfix bereits funktionsfähig konfiguriert wurde und für den Versand per Smarthost eine Authentifizierung notwendig ist.
Fangen wir damit an das Passwort zu hinterlegen. Hierzu legen wir eine neue Datei /etc/postfix/relay_password an und tragen Benutzername und Passwort ein.
/etc/postfix/relay_password
1
mail.myprovider.example myuser:mypass
Ggf. sollte die Datei über entsprechende Dateirechte vor neugierigen Blicken geschützt werden. Da Postfix üblicherweise aus geschwindigkeitsgründen Datenbankdateien nutzt müssen wir unsere Textdatei noch entsprechend umwandeln:
1
postmap/etc/postfix/relay_password
Nun bereiten wir noch eine Absenderersetzung vor. Die Datei sender_canonical biegt mWn den internen Absender um, welcher z.B. im Envelope verwendet wird, header_check kümmert sich um das FROM:-Feld. Je nach Provider kann es ausreichend sein nur eine der Varianten zu verwenden, beachtet jedoch, dass solche Mails gerne von SPAM-Filtern aussortiert werden.
/etc/postfix/sender_canonical
1
/.+/myuser@myprovider.example
/etc/postfix/header_check
1
/From:.*/REPLACE From:myuser@myprovider.example
Hier sind die Dateien als regexp deklariert und können ohne Mapping genutzt werden.
Zuletzt machen wir diese Dateien noch in der Postfix-Konfiguration bekannt:
In der ersten Zeile wird der eigentliche Server des Providers als ausgehender Server definiert – mit dieser Einstellung wird Postfix nicht mehr selbst versuchen Mails zuzustellen sondern alles an diesen weiterleiten. Im nächsten Block wird angegeben, dass für den ausgehenden Server eine Authentifizierung notwendig ist und wo die Passwörter zu finden sind. In den letzten Zeilen definieren wir unsere Filter, welche die Ersetzung vornehmen.
Nach dem nächsten Reload des MTA sollten nun alle E-Mails mit der gesetzten Absenderadresse über den angegebenen Smarthost versendet werden.
In vielen Firmen gilt noch immer Microsoft Edge bzw. der Internet Explorer als Standardbrowser für Inter- und Intranet. Einer der wichtigsten Gründe ist die Verwaltbarkeit: Updates werden über die Systemfunktionen automatisch installiert, Eintellungen lassen sich komfortabel über Gruppenrichtlinien zuweisen. Was viele IT-Abteilungen nicht auf dem Schirm haben ist, dass es auch mit alternativen Browsern nicht vollkommen unmöglich ist eine solch zentrale Konfiguration einzurichten. Hier möchte ich ein paar Kniffe für den Einsatz von Firefox in größeren Installationen geben.
Deployment und Updates
Fangen wir kurz mit Deployment und Updates an: In vielen Firmen laufen Updates des IE über WSUS. Dieser ermöglicht es Aktualisierungen erst in einem Laborumfeld auf unerwünschte Nebenwirkungen zu testen und im Anschluss an die Clients zu verteilen. Prinzipitell gut, jedoch ist WSUS hauptsächlich für Microsoft-Produkte ausgelegt, wird vom Hersteller etwas stiefmütterlich behandelt und ist – zumindest nach meiner Erfahrung – nur mäßig zuverlässig. Nicht zuletzt weil nahezu kein Unternehmen ohne Drittanbietersoftware auskommt, wird in vielen Firmen ein weiteres Deployment-System wie z.B. SCCM oder das kostenfreie OPSI zum Einsatz. Über diese kann man auch Firefox recht schnell ausrollen. Hierzu benötigt man statt dem kleinen Stub-Installer, welcher für Windows üblicherweise ausgeliefert wird, den Offline-Installer, welcher z.B. auf der Sprachübersicht zu finden ist. Wer neue Funktionen gegen seltenere Wartung tauschen möchte kann alternativ auf den „Extended Service Release“ (ESR) zurückgreifen. Hierbei handelt es sich um eine spezielle Version von Firefox, welche über einen längeren Zeitraum mit Sicherheitsaktualisierungen versorgt wird. Im Gegensatz zur Desktop-Version werden bei diesen Updates – soweit mögich – keine Funktionen verändert. Der Befehl für eine Silent-Installation lautet
1
Firefox Setup55.0.3.exe/S
Achtung: Beim Download haben 32- und 64-Bit-Varianten aktuell, trotz unterschiedlichem Inhalt, den selben Dateinamen. Über den selben Weg kann man neuere Versionen zur Aktualisierung installieren. Möchte man die Software später wieder löschen findet sich im Installationsverzeichnis eine passende Datei
Bleibt die Konfiguration. Hier lässt sich ein Überbleibsel aus der Netscape-Zeit nutzen, welche die Ausführung von Scripten beim Start des Browsers erlaubt. Im ersten Schitt legt man eine neue Datei im Ordner „%PROGRAMFILES%\Mozilla Firefox\defaults\pref\“ an. Der Name kann frei gewählt werden, jedoch erfolgt die Ausführung alphabetisch. Als inoffizielle Konvention hat sich „autoconfig.js“ durchgesetzt. Erste Falle: Die erste Zeile. Diese wird automatisch übersprungen, dort hinterlegte Befehle also ignoriert. Als Workarround sollte man in dieser folglich besser einen Kommentar unterbringen. Zweite Falle: Zwar können in dieser Datei bereits Konfigurationen gesetzt werden, jedoch wird sie während des Browserstarts zu einem Zeitpunkt geladen, an dem noch nicht alle Subsysteme verfügbar sind. Um dies zu umgehen wird stattdessen ein Verweis auf eine weitere Konfiguration hinterlegt, welche am Ende des Starts geladen wird. In diesem Beispiel nenne ich diese „mycompany.js„. Standardmäßig sind diese nachgeladenen Dateien mir ROT13 (sic!) codiert um neugierige Blicke und Änderungen von Nutzerseite zu erschweren. Da Ersteres ohnehin auch über die Browserfunktionen möglich ist und sich Schreibzugriffe über die Berechtigungen des Dateisystems effektiver verhindern lassen, schalte ich diese Funktion aus, so sind Änderungen einfacher.
Nun geht es daran die eigentliche Konfiguration zu erstellen. Die zuvor referenzierte „mycompany.js“ wird im Programmverzeichnis, also „%PROGRAMFILES%\Mozilla Firefox\„, erwartet. Für das Setzen von Konfigurationen stehen uns verschiedene Befehle zur Verfügung – hier die wichtigsten:
Befehle
pref()
So gesetzte Einstellungen sind identisch zu jenen, die der Nutzer in der GUI oder about:config vornimmt. Die Änderungen werden als „vom Benutzer eingestellt“ angezeigt. Benutzer können diese weiterhin ändern, da das Konfigurationsscript jedoch bei jedem Browserstart läuft werden die Änderungen nach dem Neustart des Browsers wider auf den vorgegebenen Wert zurückgesetzt.
defaultPref()
Hiermit wird die Standardeinstellung geändert. Der Nutzer hat auch hier die Möglichkeit diese selbstständig zu ändern, jedoch sind Benutzeranpassungen bei dieser Variante persistent und werden bei einem Neustart nicht automatisch zurückgesetzt.
lockPref()
Hiermit wird eine Einstellung gesetzt und gleichzeitig gesperrt. Sie kann im Anschluss nicht mehr vom Nutzer geändert werden, entsprechende Konfigurationsfelder werden ausgegraut.
unlockPref()
Hebt die Sperre wieder auf. Interessant wenn man z.B. mit einer globalen Konfiguration arbeitet, bestimmten Benutzergruppen jedoch Funktionen über eine weitere Konfigurationsdatei wieder freigeben möchte.
getPref()
Liest die Konfiguration – z.B. um ein „identisch zu X“ umzusetzen.
clearPref()
Löscht die Konfiguration
getenv()
Liest eine Umgebungsvariable
Wie am Namen zu erkennen handelt es sich um Javascript, man kann also auch eigene Logik einbringen. Auch hier nutze ich die erste Zeile zur Sicherheit als Kommentar. Die Bezeichnungen der Konfigurationsfelder kann man im Browser zu großen Teilen in about:config finden.
Beispiele
Automatische Updates ausschalten
Da Updates, wie oben erwähnt, über das zentrale Deployment laufen sollen, wird der Auto-Updater des Browsers ausgeschaltet. So wird der Nutzer nicht mit entsprechenden Aufforderungen konfrontiert und Änderungen können vor einem breiten Rollout in einer überwachten Umgebung auf Kompatibilität mit den Unternehmensanforderungen geprüft werden. Achtung: Einige der Updater-Einstellungen lassen sich nur mit lockPref() setzen.
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// Deaktiviert den Updater
lockPref("app.update.enabled",false);
// Stellt sicher dass er tatsächlich abgestellt ist
lockPref("app.update.auto",false);
lockPref("app.update.mode",0);
lockPref("app.update.service.enabled",false);
// Deaktiviert die Kompatbilitätsprüfung der Add-ons
SSL-Zertifikate sind bei Drittbrowsern immer eine Qual. Statt den Systemzertifikatspeicher zu verwenden bringen die meisten Browser einen eigenen Zertifikatspeicher mit. Firmen, welche interne CAs verwenden müssen hier eine separate Konfiguration erzeugen und können sich nicht auf die Verteilung per GPO o.Ä. verlassen. Bei Firefox gibt es hier die Möglichkeit über „certutil„ Zertifikate per Script zu importieren.
Bei neueren Installationen kann man Firefox jedoch instruieren auch Zertifikate zu akzeptieren, welche im Windows-Zertifikatspeicher hinterlegt sind.
JavaScript
1
2
//Accept system certificates
pref("security.enterprise_roots.enabled",true);
Proxy-Server
Verwendet die Firma einen Proxyserver, welcher nicht über den Router als „transparenter Proxy“ betrieben wird, kann dieser ebenfalls hier hinterlegt werden.
Das Erstellen von Lesezeichen ist etwas komplizierter, da man hier mit Datenbank und GUI interagieren muss, welche erst am Ende des Browserstarts zur Verfügung stehen. Um sicherzugehen, dass hier alle Module verfügbar sind, wird das Erstellen in eine eigene Funktion ausgelagert und mit einem Hook des Browsers verknüpft. Das Erstellen erfolgt über den nsINavBookmarksService. Dieser ermöglicht auch das Verwalten von Ordnern oder das Löschen von Elementen.
Wer weniger administriert und lieber herumklickt eine GUI der Textkonfiguration vorzieht kann einen Blick auf CCK2 werfen, welches die Konfiguration grafisch aufbereitet.
Es ist Laubbläserzeit – wohl dem, der Soundtechnisch dagegen halten kann. Leider sind meine Eigenbau-Mediacenter da etwas dünn aufgestellt, allerdings liegt noch ein altes, analoges 5.1-System in der Kiste. Könnte man aus dem Stereo-Ausgang des Raspberry Pi nur ein Bass-Signal für den Subwoofer erzeugen. Kann man natürlich, und eine dafür notwendige Frequenzweiche bietet ICStation.com als Bausatz an.
00:00 Warum das Ganze?
02:26 Der Bausatz
05:36 Die Schaltung
07:10 Simulation
09:45 Erste Messung
11:46 Das fertige Modul
12:00 Blick in das Audiosystem
15:05 Frequenzweiche an der Box
16:38 Ozi-Auswertung mit Last
Hinweise
Der Bausatz wurde mir von ICStation.com für dieses Video kostenfrei zur Verfügung gestellt.
Schlecht. Ein ESXi-Host sollte zwecks Update „mal schnell“ neu gestartet werden, doch nun sind mehr als 30 Minuten vergangen und es gibt noch immer kein Lebenszeichen. Selbst für Server etwas ungewöhnlich und lange genug um den VMWare-Updater in einen Timeout laufen zu lassen. Nach einiger Zeit war das System zwar wieder korrekt gebootet und zeigte keine weiteren Auffälligkeiten, eine solche Wartezeit wäre bei Störungen jedoch sehr hinderlich, also gehen wir mal auf Quellensuche.
Im Log finden sich mehrere Einträge, welche durch die Zeitstempel massive Wartezeiten erkennen lassen:
1
2
3
4
5
6
7
8
9
10
11
***T09:53:18.467Zcpu1:***)vmw_psp_mru:psp_mruSelectPathToActivateInt:346:Changing active path from NONE tovmhba0:xx:xx:xx fordevice"Unregistered Device".
***T09:53:18.467Zcpu1:***)StorageApdHandler:xxx:APD Handle Created with lock[StorageApd-0xxxx]
***T09:54:38.524Zcpu2:***)ScsiDeviceIO:xxx:Cmd(0xxxx)0x1a,CmdSN0x2from world0todev"naa.xxx"failedH:0x5D:0x0P:0x0Possible sense data:0x00x00x0.
***T09:54:38.524Zcpu1:***)ScsiDeviceIO:xxx:Could notdetect setting of sitpua fordevice naa.xxx.Error Timeout.
Das Ganze wiederholt sich dann mehrfach. Also ein SCSI-Timeout? Der Host ist per FibreChannel an diverse Storage-Systeme angebunden, sollte jedoch auch nur die für ihn relevanten LUNs sehen. Zumal nach dem langem boot auch alle Datastores verfügbar und VMs ohne Fehler online waren.
Nach einigem Suchen dann die Erkenntnis: Die angekreideten LUNs gehören zu einem Windows-Cluster und sind als RDM vorgesehen. ESXi versucht nun beim Booten diese LUNs zu scannen, was jedoch nicht gelingt da der Cluster auf einem anderen Host aktiv und die Partition somit dauerhaft gesperrt ist. Zur Abhilfe muss man diesen Scan beim Boot explizit für die betroffenen LUNs auf jedem Host deaktivieren:
Ugh – eine VM hängt und ich habe kein VPN ins zugehörige Netz. Aber jetzt extra hinfahren? Auch unschön. Glücklicherweise gibt es noch einen SSH-Zugang, den ich hier nutzen kann. Also schnell Tunneln – doch welche Ports? Nunja, nehmen wir für den „alten“ vSphere-Client folgende:
443
992
993
Wer jedoch versucht mit 127.0.0.1 oder localhost zu verbinden wird auf Probleme stoßen – bei mir lief der Client auf diesen IPs keinen Connect zu. Ein kurzer Griff in die IPv6-Kiste mit dem guten, alten [::1] half und ließ die Verbindung zu.
(Hinweis: Der Artikel lag schon etwas rum – möglicherweise sind die verwendeten Tools nicht mehr aktuell)
Hmmm – ungünstig. Das einzige optische Laufwerk steckt in einem Linux-Server, ich möchte die Discs jedoch auf einem anderen Gerät verwenden. Üblicherweise reicht hier ein File-Share wie Samba, NFS o.Ä. aus, wenn man jedoch beispielsweise kopiergeschützte DVDs abspielen möchte ist eine solche Freigabe nicht ausreichend. Glücklicherweise können wir hier einen alten Bekannten bemühen: iSCSI. Dies hatten wie bereits für Festplatten besprochen, kann aber auch für optische Laufwerke genutzt werden.
Server / Target
Nach dem Aufruf von targetcli sollten wir die altbekannte Textkonsole erhalten, welche auf der Root (/) der Konfiguration startet. Im ersten Schritt registrieren wir das physikalische Laufwerk /dev/sr0 als Backstore und aktivieren es für iSCSI. Sofern nicht bereits vorhanden wird automatisch eine TPG erzeugt.
Created pscsi storage objectcdrom_backend using/dev/sr0
/backstores/pscsi>cd cdrom_backend
/backstores/p...cdrom_backend>/iscsi create
Created target iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.3299e9a7999b.
Created TPG1.
Globalpref auto_add_default_portal=true
Created defaultportal listening on all IPs(0.0.0.0),port3260.
Nun müssen wir noch eine LUN erstellen um Clients den Zugriff zum Gerät zu ermöglichen. Diese Konfiguration findet im Kontext der TPG statt, die nötige ID wurde ja weiter oben angezeigt. Da nur ein Backstore verfügbar ist wird dieser automatisch ausgewählt. Da es sich um ein Testnetz handelt verzichte ich auf eine Absicherung und alle alle Clients zu – bei CD-Laufwerken ein überschaubares Risiko.
Zuletzt wird die Konfiguration gespeichert, so ist sie z.B. auch nach einem Neustart noch vorhanden
1
2
3
4
5
6
7
8
/iscsi/iqn.20...e8a7999b/tpg1>cd/
/>saveconfig
Last10configs saved in/etc/target/backup.
Configuration saved to/etc/target/saveconfig.json
/>exit
Globalpref auto_save_on_exit=true
Last10configs saved in/etc/target/backup.
Configuration saved to/etc/target/saveconfig.json
Client / Initiator
Auf der Clientseite benötigen wir ebenfalls eine Userspace-Software. Ich nutze zur Konfiguration iscsiadm aus dem Paket open-iscsi. Hier wird erst über Discover geprüft welche LUNs auf der TPG/Ziel-IP verfügbar sind. Über Login werden diese dann verbunden.
Wenn es eine Software gibt, welche potentiell mehr Schaden anrichten kann und schwerer zu entfernen ist als ein Virus, dann handelt es sich um ein Produkt aus der Schlangenölbranche. Ein besonderes Schätzchen ist hier Kaspersky, deren Firmenchef sich gerne als Gehilfe diverser Dienste positioniert und aktuell unter Beschuss steht. Aber genug Themenausflug – mein Wunsch ist schnell definiert: Deinstallieren. Vorzugsweise automatisch. Nicht wegen den aktuellen Problemen, sondern eher da die Systeme sauber sein sollen.
Kaspersky besteht dabei in der Business-Variante aus drei Teilen:
Das Kaspersky Security Center (KSC, ehemals Kaspersky Administration Kit oder auch KAK), welches zentral installiert ist und für Management und Deployment zuständig ist
Der Kaspersky Administration Agent, einem kleinen Tool, welches auf allen Rechnern installiert ist und primär die Verbindung zwischen dem Security Center und den Schutzprogrammen des Rechners herstellt. Weiterhin kann es zur Installation von beliebigen Programmen und Patches genutzt werden.
Zuletzt das eigentliche Schutzprogramm, auf Nutzerseite meist Kaspersky Endpoint Security, welches Dienste wie Signaturscan, Software-Firewall und Gerätekontrolle bereitstellt.
Leider ist das Management an vielen Stellen trotz der langen Reife noch ausbaufähig. Verschiedene Sprachversionen oder gar Rechner mit unterschiedlichen Service-Packs der Software lassen sich nur schwer gemeinsam verwalten oder gegeneinander austauschen, die Managementverbindung geht gerne mal verloren und für die Rechnergeschwindigkeit ist eine solche Software ebenfalls nur wenig zuträglich.
Zur Deinstallation hatte ich hierzu üblicherweise eine „Geheimwaffe“: Den KAVRemover. Dieses Tool des Herstellers ist in der Lage viele Installationen auf dem verwendeten Rechner mit einem Schlag zu entfernen. Aus Sicherheitsgründen hat sich der Hersteller jedoch dazu entschieden die Deinstallation mit einem CAPTCHA abzusichern. Da ich nun eine größere Charge Rechner vor mir hatte tut diese Unmöglichkeit der Automation natürlich weh. Also ran an die offiziellen Deinstallationsroutinen.
Erstes Problem: Passwörter. Insgesamt gibt es 2-3 Passwortebenen, mit denen eine lokale Installation im genannten Konstrukt geschützt ist:
Endpoint Security nutzt, wenn in der entsprechenden Policy angegeben, einen Passwortzugang zu allen administrativen Funktionen. Dieses wird auch zur Deinstallation benötigt. Bei neueren Versionen (ab 10.2ish) wird zusätzlich ein Benutzername verlangt, welcher jedoch augenscheinlich auf „KLAdmin“ hardcoded ist.
Ist dieses Passwort nicht bekannt, jedoch Zugang und Verbindung zum Security Center noch vorhanden, kann man den Passwortschutz per Policy einfach ausschalten und so die Deinstallation etwas vereinfachen. Hierzu öffnet man die zum Produkt gehörende Policy und entfernt unter „Advanced Settings“ -> „Interface“ die Checkbox „Enable password protection“. Dies muss selbstverständlich für jede Sprache und Service-Pack-Version wiederholt werden.
Der Administration Agent nutzt eine separate Policy und hat ein dediziertes Passwort für die Deinstallation gesetzt. Ob sich dies ebenfalls irgendwo abschalten lässt habe ich nicht geprüft.
Das Passwort lässt sich glücklicherweise bei der Deinstallation als Parameter – natürlich je nach Version mit anderem Namen – angeben. Um die Funktion nutzen zu können muss man das Passwort jedoch vorher umrechnen: Es muss als ASCII-String einer HEX-Repräsentation des Passworts als 16Bit-ASCIIish (sieht aus wie ein Byte-Invertiertes UTF16) eingetragen werden. Besser keine Fragen stellen.
Also rechnen wir mal: Wäre unser Passwort „Geheim“ müssen wir dies erst mal in Hex konvertieren. Hierzu kann man – bei einfachen Zeichen – die gute, alte ASCII-Tabelle bemühen. G ist in HEX 0x47, e 0x65 – und so weiter. Am Ende erhalten wir „47 65 68 65 69 6D“. Da wir jedoch noch die 00en für 16 Bit brauchen wird daraus ein „470065006800650069006D00“. Mit diesem String können wir dann weiter an’s Werk. Zu beachten ist, dass einige Versionen der 10er-Serie (10.0.3361) zwischendrin plötzlich mal nur 8 Bit brauchten um beim nächsten Update wieder auf 16 zu springen. Kurzfassung: Wenns nicht geht einfach anders nochmal versuchen.
Für die Deinstallationen benötigt man weiterhin die MSI-IDs der Produkte. Einige seien hier mal gelistet, wer weitere hat: Die Kommentare stehen offen. Wer sich nicht sicher ist sollte in der Registry unter HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall und HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall nach Kaspersky-Einträgen suchen.
Danke an dawinci für das Listen der auswärtigen Agent-IDs
Beim Admin-Agent schlägt die Installation teilweise trotz richtigem Passwort mit dem Exit-Code 1603 fehl. In dem Fall kann es helfen einfach mal bis 10 zu zählen und die Deinstallation nochmal zu starten.
Bei /qb- wird ein Fortschrittsbalken angezeigt, welcher leider auch „abbrechen“ ermöglicht. Alternative /qn komplett im Hintergrund.
In meinem Fall habe ich eine Loop, welche für jede bekannte MSI-ID alle Deinstallationsbefehle mehrmals durchprobiert. Bei ca. 90% der Rechner funktioniert holzhammer(); – immerhin etwas weniger Arbeit.
Eine LED in die Steckdose stecken klingt nicht sonderlich klug – aber seit wann lasse ich mich davon abhalten. Schauen wir mal was passiert, warum man nicht wie sonst einen Vorwiderstand nutzen sollte und was ein Kondensator damit zu tun hat.
Teslaspulen sind immer faszinierend – und das nicht nur in alten Computerspielen. Durch hochfrequente Wechselspannung und ein großes Übersetzungsverhältnis wird eine Hochspannung generiert, welche optisch interessante Plasmablitze erzeugt. Klingt nach Raketentechnik? Nicht ganz – für ein paar Euro verspricht dieser Bausatz von ICStation.com nicht nur einen einsteigerfreundlichen Aufbau, sondern auch gleich noch eine Musikfunktion.
Achtung: Hochspannung ist gefährlich. Nicht ohne Schutzmaßnahmen betreiben.
Mal wieder ein Fehler, der im ersten Moment nicht wirklich zu erklären ist: An einem meiner Mediacenter konnte ich mich nicht mehr per SSH anmelden. Alle anderen Netzwerkfunktionen sahen OK aus, der SSH-Client meines Rechners zeigt jedoch folgendes:
Da es vor dem „Authentication failed“ ein paar Sekunden Wartezeit gibt kam mir ein alter Bekannter in den Sinn: DNS. Meldet man sich per SSH an versucht dieser standardmäßig den zur IP gehörenden Hostname zu ermitteln. Erhält der SSH-Daemon keine Antwort kann es zu einem Timeout kommen und die Verbindung abbrechen. Auch in meinem Fall fand ich in der Konfiguration einen veralteten DNS-Server.
Die ultimative Lösung besteht natürlich darin die Netzwerkkonfiguration zu fixen und somit DNS wieder lauffähig zu bekommen. Um zukünftig den hier nötigen Gang zum Raspi zu sparen und SSH auch ohne DNS lauffähig zu bekommen kann man folgende Zeilen in /etc/ssh/sshd_config hinzufügen:
/etc/ssh/sshd_config
1
2
GSSAPIAuthentication no
UseDNS no
UseDNS schaltet den Reverse-DNS ab – im LAN wohl zu verkraften. GSSAPI kann ohne DNS ebenfalls Fehler verursachen und wird bei einfachen Setups ohnehin nicht aktiv sein, daher auch dies nochmal explizit abgeschaltet. Nach dem nächsten Neustart des sshd sollte der Login dann auch ohne DNS immer und so die Reparatur der Netzwerkkonfiguration auch übers Netz möglich sein.
Warning: Nerd inside
In eigener Sache: Unsere Kontaktdaten werden immer häufiger von Unbekannten im Internet missbraucht. Weitere Infos und Erklärungen finden Sie auf dieser Seite.
Diese Webseite nutzt Cookies. Da diese ein essentieller Teil aktueller Webtechniken darstellen und viele Funktionen des Internets durch diese Technik erst ermöglichen gehen wir davon aus, dass sie mit der Verwendung von Cookies einverstanden sind. Sie können die Nutzung von Cookies in den Einstellungen ihres Browsers abschalten. AkzeptierenWeitere Infos
