Schlagwort-Archive: ssh

PC-Kram

VMWare vSphere-Client per SSH-Tunnel

Schreibe einen Kommentar

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2016/07/vmlist-300×205.pngUgh – 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.

PC-Kram

RasPi/OSMC: SSH-Login bricht ab

Schreibe einen Kommentar

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:

> ssh osmc@1.2.3.4 -v
OpenSSH_7.5p1, OpenSSL 1.1.0f  25 May 2017
debug1: Reading configuration data /home/adlerweb/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug1: Connecting to 1.2.3.4 [1.2.3.4] port 22.
debug1: Connection established.
[…]
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Raspbian-5+deb8u3
debug1: match: OpenSSH_6.7p1 Raspbian-5+deb8u3 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 1.2.3.4:22 as 'osmc'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:xyz
debug1: Host '1.2.3.4' is known and matches the ECDSA host key.
debug1: Found key in /home/adlerweb/.ssh/known_hosts:853
debug1: rekey after 1234 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 1234 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
Authentication failed.
>

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:

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.

Software

Veeam B&R: „Auf das verworfene Objekt kann nicht zugegriffen werden. Objektname: System.Net.Sockets.Socket“

Schreibe einen Kommentar

Tolle Meldung, die das Backupsystem „Veeam Backup&Replication“ da abwirft:

Auf das verworfene Objekt kann nicht zugegriffen werden. Objektname: "System.Net.Sockets.Socket"

…heißt es lapidar in der GUI, die sonst nur darüber informiert, dass kein Backup mehr funktioniert. Zwar ist recht klar, dass es am Netzwerk hängen dürfte, da hier aber pro VM-Sicherung mindestens 5 Server involviert sind gestaltet sich das etwas aufwändiger.  Vor allem wenn alle relevanten Systeme fehlerfrei auf ICMP-Ping reagierten.

Tiefer im Log des Jobs fand sich eine Meldung, welche auf einen Fehler des Backupziels hindeutet. In meinem Fall handelt es sich hierbei um einen Linux-Server, welcher übers Netz beschickt wird.

<19> Info     [Ssh] Server (nas5.lan.adlerweb.info) version string: "SSH-2.0-OpenSSH_7.2"
<19> Info     Channel encryption check: *** to ***
<19> Info             [AP] Starting client agent on 'nas5.lan.adlerweb.info'
<19> Info             [AP] Linux kernel version [uname -r]:
<19> Error    Failed to check kernel version. Supported Linux kernel version is assumed.

Uhmk? Im Monitoring war nichts zu sehen, außerdem kommt ja der SSH-Header. Schnell mal per KVM auf die Kiste und geprüft:

# uname -a
Linux nas5 4.4.10-1-lts #1 SMP Wed May 11 21:03:02 CEST 2016 x86_64 GNU/Linux
#

Also uname sollte also funktionieren. Auch der SSH-Daemon läuft noch. Im Log sind jedoch einige Meldungen, die möglicherweise das Problem beschreiben:

nas5 dbus[**]: [system] Failed to activate service 'org.freedesktop.login1': timed out
nas5 sshd[**]: pam_systemd(sshd:session): Failed to create session: Failed to activate service 'org.freedesktop.login1': timed out
nas5 sshd[**]: pam_systemd(sshd:session): Failed to create session: Failed to activate service 'org.freedesktop.login1': timed out

freedesktop? Das ding ist Xless -.-. Übeltäter ist wieder einmal „Server sind ja nur Ausnahmeerscheinungen“ Systemd. Dessen Loginmanager bekommt Schluckauf wenn, z.B. im Rahmen von Updated, dbus neu gestartet wird. Als Ergebnis lässt sich PAM bei Logins durchaus mal 15 Sekunden Zeit um in den Timeout zu laufen. Je nach Client/Verbindungsart kann dies jedoch bereits zum Timeout der gesamten Verbindung führen – und nichts geht mehr. um den Fehler zu beheben reicht es aus den Logind neu zu starten:

systemctl restart systemd-logind

Warum ein System, was sonst ja auch alles „on demand“ startet/stoppt/überwacht, sowas seit offenbar langer Zeit nicht in den Griff bekommt bleibt offen. Ebenso wie die Frage, warum Veeam keine genaueren Fehlermeldungen liefert.

Software

ArchLinux: Update sperrt root-Login per SSH

Schreibe einen Kommentar

Ouch – nicht schön. Nach dem Update einer remote-Kiste war der Login per SSH nicht mehr möglich. Schuld ist offenbar eine Änderung der SSH-Defaults: Während bisher der root-Login auch ohne explizite Angabe in der Konfiguration erlaubt war, muss dies nun in der Konfiguration mit einem PermitRootLogin yes manuell zugelassen werden. Sofern kein anderes Konto besteht heißt das nach einem Update dann: KVM oder Remote-Hands müssen her um den Eintrag zu setzen und den Server so wieder verwaltbar zu machen. Ein Hinweis vorab wäre natürlich einfacher gewesen :/.

Edit: Zu früh gemault: Im Announcement der OpenSSH-Leute ist die Änderung beschrieben, RTFM hätte also geholfen…

Potentially-incompatible Changes
—
[…]
* The default for the sshd_config(5) PermitRootLogin option has
changed from „yes“ to „prohibit-password“.

Software

SSH Root-Login auf Debian Jessie aktivieren

Schreibe einen Kommentar

„Mal schnell“ einen Server mit Debian aufsetzen – kann ja nicht so schwer sein. Dachte ich. Eine Kleinigkeit ist jedoch zu beachten: Mit der tasksel-Auswahl „SSH-Server“ wird dieser zwar installiert und passend gestartet, standardmäßig ist der Login jedoch nur mit dem zusätzlich erstellten User möglich, nicht jedoch als root.

Da ich für den Server Remote-Scripte laufen habe, welche bisher nicht auf ein User->sudo-System ausgelegt sind, ist für mich ein SSH root-Login unumgänglich. Um diesen auf dem Debian-System zu aktivieren öffnet man die Datei /etc/ssh/sshd_config und entfernt bzw. kommentiert (# davor) die folgende Zeile:

PermitRootLogin without-password
BitBastelei

BitBastelei #146 – SSH unter Linux

Schreibe einen Kommentar
BitBastelei #146 - SSH unter Linux

(41 MB) 00:30:06

2015-04-26 10:00 🛈

Vom Verbinden bis zum Tunneln
Alle Angaben beziehen sich auf OpenSSH

Befehle:

Verbinden zum Rechner:
ssh evil.server

Verbinden zum Rechner mit Nutzerangabe
ssh anderernutzer@evil.server

Host-Keys anzeigen
ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key
(bzw. passender Key)

Host-Key aus „Adressbuch“ löschen
ssh-keygen -R evil.server

Neues Schlüsselpaar erzeugen
ssh-keygen

Key auf Server kopieren
ssh-copy-id username@evil.server

Passwort eines Keys ändern
ssh-keygen -f ~/.ssh/id_rsa -p

Argumente
-p 1234 – Port 1234 statt Port 22 nutzen
-C – Kompression einschalten
-v – verbose – zusätzliche Ausgaben zur Fehlersuche

Lokale Weiterleitung
ssh -L 127.0.0.1:1234:192.168.0.2:80 evil.server
Lokale Verbindungen an Port 1234 werden über evil.server an 192.168.0.2 Port 80 weitergeleitet

Remote Weiterleitung
ssh -R 0.0.0.0:1235:127.0.0.1:80 evil.server
Verbindungen auf eine beliebige IP von evil.server auf Port 1235 werden an Port 80 des lokalen PCs weitergeleitet

SOCKS-Proxy
ssh -D 3128 evil.server
Es wird ein SOCKS-Proxy auf Port 3128 gestartet. Dieser kann z.B. mit Firefox genutzt werden

X11-Forwarding
ssh -XY evil.server
Nun können in der Sitzung grafische Programme gestartet werden. Die Anzeige erfolgt auf dem lokalen PC

Config-Files
Alle Argumente und weitere Optionen können global oder pro Ziel in den Konfigurationen hinterlegt werden. Die Benutzerkonfiguration ist unter ~/.ssh/config zu finden, die Systemweite üblicherweise unter /etc/ssh/ssh_config

Escape-Sequenz
In einer SSH-Sitzung kann man üblicherweise mit der Tilde-Taste (~) ein internes Menü aufrufen. Die Wichtigsten Befehle:
~? Hilfe anzeigen
~. SSH-Verbindung beenden (auch wenn Gegenseite nicht mehr reagiert)
~# Liste der Verbindungen (incl. Tunnel) anzeigen
~C Interne Konsole aufrufen – hier kann man nachträglich Tunnel (-L, -R, -D) aufbauen

Weitere Ideen:
– ssh-agent: Kennwörter für SSH-Keys mussen nur alle X Minuten eingegeben werden
– autossh: SSH-Verbindung bei Abbrüchen neu Aufbauen
– SSH mit Pipes: Pipes lassen sich über SSH auch an entfernte Rechner senden
– 2-Faktor-Anmeldung, z.B. mit Google Authenticator
– Host-Keys in DNS hinterlegen

LUG-MYK

Software

VMWare ESXi 5.x – SSH aktivieren

Schreibe einen Kommentar

VMWare ESXi basiert intern auf einem Unix-artigen System, entsprechend kann ab und an ein kleiner Schubs auf der Konsole recht hilfreich wirken. Zwar ist im System von Haus aus ein SSH-Server vorhanden, jedoch üblicherweise deaktiviert.

Um einen SSH-Zugang zu aktivieren klickt man im vSphere-Manager den Host an und wählt rechts den Tab „Konfiguration“ aus. In der linken Seite befindet sich unter „Software“ der Menüpunkt „Sicherheitsprofil“. Unter Dienste ist SSH bereits geführt, jedoch nicht gestartet – dies kann man über den kleinen Link „Einstellungen“ an der rechten Seite ändern. Unter SSH->Optionen lässt sich der Dienst dauerhaft aktivieren oder auch nur für einen kurzen Eingriff manuell starten.

Bild: https://adlerweb.info/blog/wp-content/uploads/2014/07/vm1-300×196.png

Der zugehörige Artikel bei VMware wäre 2004746

Software

SSH: X11 connection rejected because of wrong authentication.

Schreibe einen Kommentar

„Mal schnell“ eine GUI über SSH aufrufen – normal kein Problem: Wenn auf dem Server X11Forwarding in der Datei /etc/ssh/sshd_config auf yes steht lässt sich mit ssh -vCXY user@host eine Verbindung starten, welche GUI-Aufrufe auf dem lokalen Rechner darstellt.

Heute leider nicht: GUI-Aufrufe verabschiedeten sich mit folgender Meldung:

X11 connection rejected because of wrong authentication.

An der SSH-Verbindung konnte man nichts sehen, diese Endete mit

debug1: Requesting X11 forwarding with authentication spoofing.

, also ohne Fehler.

Das Problem ist mal wieder aus der Kategorie „so einfach, dass man es übersieht“: Die Platte war voll…

df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda6 29G 28G 0 100% /

Nachdem wieder etwas Platz verfügbar war ging auch x11 per SSH wieder fehlerfrei.

Software

Sniffing over the Net – Mit Wireshark und tcpdump auf entfernten PCs sniffen

Schreibe einen Kommentar

Ja, ich weiß, Paket-Sniffer sind böse Hackertools und so weiter – wer das Denkt sollte hier aufhören zu lesen und erst eine Prise Praxis zu sich nehmen. Gerade wenn es um das Debuggen von Fehlern in Netzwerkverbindungen geht kommt man nur schwer dran vorbei – wenn man nicht gerade zwischen den Geräten sitzt wird es jedoch schnell ungemütlich. Gehen wir fon folgender Konstellation aus, welche bei mir derzeit aufgetreten ist: Ein Mobilgerät kommuniziert mit einer Webbasierten API über HTTP – der Server steht nicht unter meiner Kontrolle und das Mobilgerät ist selbstverfreilich entsprechend vernagelt. Natürlich könnte man nun einen Monitoring-Port an einem Switch zwischen Mobilgerät und Internetzugang nutzen, aber der liegt weit entfernt und ich müsste zwischen zwei Orten pendeln.

Bisher hieß das für nicht: 2-Schritt-Debugging. Erst verband ich mich auf den (Linux-basierten) Router, fertigte mit tcpdump ein Capture-File an und lud es auf den PC um in Wireshark einen Blick in die Pakete zu werfen. Dank eines Hinweises auf einen Artikel bei Commandlinefu kann ich mir das nun sparen – dank Pipes und ssh lassen sich tcpdump und Wireshark so verschalten, dass ein Live-Capture des Remote-Servers im lokalen Wireshark einläuft. Macht das Ganze wesentlich einfacher…

Ein möglicher Befehl wäre z.B.

ssh root@internetrouter tcpdump -i eth0 -U -s0 -w - 'port 80 and host 192.168.1.2'  | wireshark -k -i -

der letzte Teil des SSH-Commands entspricht den üblichen tcpdump-Filtern – hier sollte man auf jeden Fall drauf achten, dass man den ssh-Traffic nicht mitschneidet – in diesem Fall ists durch die Host/Port-Einschränkung ja ohnehin gegeben, ansonsten sollte ein ’not port ssh‘ helfen.