.LNX-WORLD

Auf dem VMware ESXi in Version 4.0 war es noch relativ umständlich SSH zu reaktiveren (hier das alte HowTo). Auf dem neuerem VMware ESXi 4.1 ist es deutlich einfacher geworden! Bei Zugriff auf die VMware Konsole des Servers genügt:

• Drücken der F2 Taste
• Troubleshooting Options
• SSH aktivieren

Viel einfacher geht es nicht. SSH lässt sich seit VMware ESXi 4.1 allerdings auch über den VMware vSphere Client aktivieren, einfach in die Options gehen. Näheres ist in der unten verlinken VMware Knowledge Database auch beschrieben.

Ich kann wie immer nur dem Weg über die Konsole empfehlen – VMware Hardcare Konfigurationen nimmt man einfach ohne GUI vor – das gehört sich so!

Weblinks:

• VMware Knowledge Database
• Veeam RootAccess

VMware ESXi 4.0 – SSH (re) aktivieren
SSH Zugriff auf ESX Server ist etwas an das man sich gewähnt hat und das man oftmals auch braucht. Leider hat VMware beim ESXi 4 eben diesen SSH Zugriff deaktiviert. Selbst an die Konsole, also den Linux Teil des ESX, kommt man nur mir Tricks.

Leider sind diese Tricks durch VMware in keinster Weise supported, aber was stört das, wenn dafür SSH und Konsole auf dem ESXi wieder benutzbar werden?

Trick 1: Zugriff auf die Konsole nehmen
Sobald der ESXi Server hochgefahren ist, also der “Wellcomescreen” zu sehen ist, direkt am VMware ESXi Server auf der Tastatur ALT-F1 drücken, nicht wundern das man keinen Cursor sieht und das Wort “unsupported” ohne “” eintippen, die Eingabe mit ENTER bestätigen. Wenn man sich nicht vertippt hat, wird nun das Rootkennwort abgefragt -> eingeben und hat Zugriff auf die Konsole des ESXi Servers!

Trick 2: SSH (re)aktivieren
Sobald man sich wie in Trick 1 beschrieben Zugriff auf die ESXi Konsole ermöglicht hat, öffnet man sich direkt auf dem VMware ESXi mit dem vi die Datei /etc/inetd.conf
Hier entfernt man mit dem vi an den beiden Zeilen für SSH das führende # (einfach den Cursor dort hinbewegen und einmal x drücken, danach bei Zeile 2 das Ganze einfach nochmal, speicher und beenden des vi geht mit :wq – den Doppelpunkt wirklich mittippen!). Danach sollte die Sektion in etwa so aussehen:

# Remote shell access #
ssh stream tcp nowait root /sbin/dropbearmulti dropbear ++min=0,swap,group=shell -i -K60
ssh stream tcp6 nowait root /sbin/dropbearmulti dropbear ++min=0,swap,group=shell -i -K60

Nun am besten den VMware ESXi Server durchbooten, um die Änderungen wirksam werden zu lassen. Sollte ein Reboot des Systems nicht so einfach möglich sein (das soll ja bei produktiven Servern manchmal zu ungemütlichen Telefonanrufen führen), muß der inetd manuell neu gestartet werden.

Trick 3: inetd manuell neu starten
Zuerst muss die Prozess ID des inetd ermittelt werden. Dies macht man auch direkt auf der Konsole des VMware ESXi, mit dem Kommando:

ps aux |grep inetd

Die Ausgabe des Kommandos sollte in etwa so aussehen:

4896 4896 busybox inetd

Die erste und zweite Spalte der Ausgabe ist die Prozess ID! Diesen Prozess beenden wir dann manuell mit dem Kommando:

kill -HUP PID

Wobei PID für die zuvor ermittelte Prozess ID steht! Nun sollte der SSH Zugriff funktionieren. Alles weitere was man nun machen muß um sich per SSH mit dem VMware ESXi Server zu verbinden, solltet ihr selbst wissen ;)

Der “iPhone Wurm” ist in einer neuen Variante unterwegs!
Diese Variante verändert das Root Kennwort eures iPhones, sofern euer Gerät einem Jailbreak unterzogen wurde! Vor ein paar Tagen hatte ich noch gebloggt (hier) wie man die SSH Kennwörter ändert und wie das Kennwort in den default Einstellungen lautet.  Nun könnte es sich für jeden iPhone Nutzer mit jailbreak als extrem vorteilhaft gestalten diese Kennwörter durch eigene ausgetauscht zu haben.

Zuerst ging es nur darum das eigene iPhone zu sichern, nun muß man diese Sicherung tatsächlich vornehmen, bevor einem eine Schadsoftware wie dieser Wurm das iPhone völlig verkonfiguriert und man sich so eventuell sogar selbst aussperrt. An alle die ihre Kennwörter noch nicht geändert haben:

Schützt euch, eure Daten und euer iPhone! Ändert die SSH Kennwörter, installiert sbSettings mit dem “SSH Schalter”, stellt SSH nur an wenn ihr es wirklich braucht und stellt via BossPrefs SSH bei Start des iPhone auf “aus”!

Wenn euer iPhone per SSH nicht mehr mit dem default Kennwort “alpine” erreichbar ist (am besten per SSH garnicht zu erreichen), kann euch der Wurm wenig anhaben. So weit ich informiert bin, ist euer iPhone dann sogar immun gegen den iPhone Wurm – ebenso als hätte euer iPhone keinen Jailbreak!

Quelle:
Winfuture

Zitat frei nach granworld :
“Ist doch klar das der Wurm in den Apfel will. Kein Wurm der Welt fühlt sich woanders wohler als in einem Apfel. Vor allem wenn der dazu noch lecker angebissen ist…”

iPhone Gefahr SSH
Fast alle iPhones mit jailbreak, also entsperrte oder jailbroken iPhones, sind in Gefahr, wie uns die Pressemeldungen der letzten Wochen recht gut verdeutlicht haben.

Nicht nur das viele iPhone nette Meldungen auf dem Display hatten, sondern auch durch die bereits existierende Virengefahr (z.B. der Wurm “privacy.A”)  ist es ratsam das iPhone ebenfalls effizient zu schützen. Hierbei geht es weniger um eine Software die man installieren muss (nein, wir sind ja nicht in der Fensterwelt), sondern vielmehr um Sicherungsmaßnahmen, die viele einfach nur nicht machen weil sie zu bequem sind!

Mit dem Jailbreak kommt meist auch der openSSH Server mit auf das iPhone, jedoch wird das Kennwort vom administrativem Benutzer Root nicht geändert. Das per default eingestellte Kennwort “alpine” kennt nun auch fast Jeder (spätestens jetzt  ;) ) und so ist es kein Wunder wenn sich alle Welt auf das iPhone einloggen kann. Mit dem benutzer Root haben diese “Fremden” dann obendrein Zugriff auf ALLE Teile von iPhne, es ist nichts mehr geschützt, bzw. verborgen! Das Kennwort vom Benutzer Root muss also dringend geändert werden! Mehr…

[aartikel]B001H30QNU:left[/aartikel]
SSH absichern – ich sagte es schon in Teil 1 dieser Reihe – dies ist etwas, dass jeder der Linux Server betreibt (egal ob in einem Firmennetzwerk, direkt über das Web erreichbar, oder beides) mit als erstes in den Angriff nehmen sollte.

In diesem Teil 2 der Reihe “SSH absichern” gehe ich auf einen Punkt ein, welcher oftmals schlicht unterschätzt wird: Den SSH Port ändern! Wenn man im Mittelalter nicht wollte, dass jemand einen Schatz fand, bzw. einen geheimen Ort, dann wurde dieser versteckt. Genauso funktioniert das gute alte Kinderspiel des Versteckens.

Was damals funktionierte, tut auch heute noch seine Wirkung! Denn beim den simplen Portscans auf offene SSH Zugänge wird meist nur nach dem default Port von SSH gesucht, dem Port 22. Was nun wenn der Server bei Anfragen auf den SSH Port 22 ganz simpel nicht antwortet? Meist fliegt man aus der Liste der Server die per Script und Brute Force angegriffen werden sollen, zumindest ist dies mein Ergebniss aus den Erfahrungen der Vergangenheit. Mehr…