Nunja, aber da schreib ich mal wann anders drüber. Hier und heute will ich in ein paar kurzen Schritten erklären, wie man diverse Magento Erweiterungen trotz nicht funktionierendem Magento Connect im Adminbereich via SSH installiert.

1. Loggt euch via SSH auf euren Server ein.
2. Wechselt in das Magento Root-Verzeichnis.
3. Gebt euch für die Installation und Einrichtung unbedingt root-Rechte am Server. Zum Beispiel kurz mit dem Befehl “su” .
4. Tippt in die Konsole folgenden Befehl ein: “./pear mage-setup”
   Wenn alles glatt läuft solltet ihr folgende Ausgabe sehen:
   Running initial setup…
   config-set succeeded
   …
   config-set succeeded
   Adding Channel “connect.magentocommerce.com/core” succeeded
   Discovery of channel “connect.magentocommerce.com/core” succeeded
   Adding Channel “connect.magentocommerce.com/community” succeeded
   Discovery of channel “connect.magentocommerce.com/community” succeeded
   
5. Anschließend könnt ihr jedes beliebige Modul installieren. Zum Beispiel für einen deutschen Online-Shop das wichtigste freie Plugin von symmetrics. Nämlich “Market Ready Germany“
6. Tippt folgendes in die Konsole ein: “./pear install -f magento-community/market_ready_germany”
7. Wenn die Installation erfolgreich war, gibt es die Ausgabe in der Konsole auch an.
8. Wechselt ihr dann in den Adminbereich des Magento Shops sind die Erweiterungen vorhanden.

… so, das wars auch schon.

Jo! Dickes Ding…

Schwupps, war der Bot drauf und startete. Das sah dann per “ps aux” so aus:

Den genauen Befehl gebe ich hier mal nicht Preis. Wer weiß wer was damit bei anderen anrichten möchte.

Wow!… immer noch erstaunt .

Die Datei udp.pl mithilfe der Lücke und “sh -c perl” über die config.inc.php von phpMyAdmin einfach gestartet.

Irre!

Die Lücke ist so riesig, dass man über ein paar witzige Handgriffe den Server darüber so gut wie steuern kann (Vorausgesetzt man hat bei der Rechtevergabe geschlampt!). Mit Aufruf: 
http://…/php_my_admin/config/config.inc.php?p=phpinfo(); kann man sich schön die Komplettinfo zum Server holen oder mit http://…/php_my_admin/config/config.inc.php?c=ps%20aux den Inhalt des tmp-Ordners. Dieser war in diesem Fall angefüllt mit dem BOT.

Mehr poste ich nicht, animiert nur zu wilden Gedanken . Habs aber gleich auf befreundeten Systemen mal ausgetestet und siehe da, viele haben die Lücke nicht geschlossen. Denjenigen habe ich mal schnell ne Mail geschrieben.

Schnell mal mit “last -i” nach komischen Logins gefahndet, dann noch known_hosts und ssh-key’s überprüft und die /etc/passwd nach lustigen neuen Usern mit UIDs “0″ durchsucht. War aber nix ungewöhnliches. Glück gehabt. Schnell phpMyAdmin aktualisiert, die tmp-Verzeichnisse geleert, und restliche Komponenten wie php, apache usw. aktualisiert und Server neu gestartet (Windows angewohnheit ).
Nun noch mit “apt-get rkhunter install” nen RootKitHunter installiert und das System durchgecheckt und mit “netstat -nap” und “netstat -tulpe” die Ports gecheckt … Und auch alles in Ordnung.
Anschließend den eaccelerator neu kompiliert und schwupps… Livesystem nach 3 Stunden wieder clean. Downtime… summiert ca. 5 min… klasse Job! Blog schreiben 30 min . Schöner Sonntagabend.

Anschließend Serverseitig noch weitere Möglichkeiten mit ein paar Tricks unterbunden. Alles soll man nicht verraten .

Was ich daraus gelernt habe:

1. Öfters mal ins Error und Accesslog vom Apachen schauen,
2. apt-get upgrade/update/install sollte ein Freund werden,
3. … meine Linux-Kenntnisse sind noch gut

Wollen wir mal schauen, ob das alles war. Der Server bleibt die Tage unter Beobachtung.

Hier eine kleine hilfreiche Anleitung

1. Schritt: Beendet den laufenden MySQL-Server über das Init-Skript:

# /etc/init.d/mysql stop

Prüft mittels ps ax ob alle Instanzen des MySQL Servers beendet wurden und beendet diese wenn nötig über ein kill -9

2. Schritt: Startet den MySQL-Server mit deaktivierter Passwort-Überprüfung und ohne Netzwerkunterstützung:

# mysqld –user=mysql –pid-file=/var/lib/mysql/mysqld.pid –socket=/var/lib/mysql/mysql.sock –datadir=/var/lib/mysql –skip-grant-tables –skip-networking

Dieser Schritt führt dazu das die von euch verwendete Konsole gesperrt wird und so lange der MySQL Dienst läuft nicht verwendet werden kann. Bitte loggt euch also über eine zweite Konsole erneut auf eurem Server ein.

3. Schritt: Setzen des neuen MySQL root Passworts:

# mysql
> use mysql
> update user set password = password (‘neues Passwort’) where user = ‘root’;
> flush privilieges;
> exit

4. Schritt: Neustart des MySQL im normalen Modus:

Beendet den aktuellen MySQL Dienst entweder über ein kill oder über die Tastenkombination STRG + c innerhalb des MySQL Fensters.

Prüft mittels ps ax ob alle Instanzen des MySQL Servers beendet wurden und beenden Sie diese wenn nötig über ein kill -9

Startet den MySQL Dienst wieder normal.
# /etc/init.d/mysql restart

fertig…

Zuerst erstellt man ein Schlüsselpaar:
(Falls noch nicht vorhanden… Folgender Befehl überschreibt das vorhandene Schlüsselpaar!)

• ssh-keygen -b 2048 -t rsa

Dann muss man den Schlüssel auf den anderen Rechner übertragen:

• ruser:~ > ssh ruser@anderer.server.de \ “umask 077; mkdir -p .ssh; cat >> .ssh/authorized_keys” <.ssh/id_rsa.pub

Der lokale öffentliche Schlüssel wird somit in die Datei ~/.ssh/authorized_keys geschrieben. Gleichzeitig wird in die lokale Datei ~/.ssh/known_hosts der öffentliche Schlüssel des Remotesystems geschrieben.

Falls es nicht funktioniert und er weiterhin ein Passwort haben möchte, einfach mal im Config-File des Servers überprüfen ob PubkeyAuthentification aktiviert ist!

und weiter gehts…