PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Freies Java Servlet für den SSH-Zugriff via Loopback?


Agent_no1
2007-09-12, 09:58:09
Hi Leute,
sagt mal wisst ihr vielleicht ob es zur Zeit ein freies (GNU/GPL) Java-Servlet gibt, welches den SSH-Zugriff (V2) ermöglicht?
Dabei ist mir wichtig, dass ich z.B. von aussen den Port 22 sperren lassen kann, lokal auf dem Linux-Host jedoch den SSH-Zugriff via Loopback-Adapter erlaube und somit einen Web/Applikationsserver laufen lassen kann, wo ich über den Browser per Java Zugriff auf das System erhalte.
Gibt es sonst noch irgendwie eine andere Methode, mit dem SSH-Server des Hosts zu verbinden, ohne von Außen den Port 22 öffnen zu müssen?
JTA habe ich schon ausprobiert, ist jedoch ein Applet und wird somit durch die JAVA Runtime immer vom Client aus ausgeführt, wodurch man mit einem Connect auf 127.0.0.1 immer nur sich selbst aufruft/mit sich selbst verbindet, nicht jedoch mit dem Host auf dem das Applet/Servlet liegt.
MindTerm ist in der Version 2 inzwischen kostenpflichtig geworden und läuft auch nur als Applet.

Danke schonmal im voraus

Viele Grüße
Agent_no1

Gast
2007-09-12, 12:28:36
Humm... Java-Anwendungen laufen doch auf dem Client, nicht auf dem Server.

Gibt es sonst noch irgendwie eine andere Methode, mit dem SSH-Server des Hosts zu verbinden, ohne von Außen den Port 22 öffnen zu müssen?
SSH-Server auf einen anderen Port schieben?

Agent_no1
2007-09-12, 12:53:23
Das macht Ihn dennoch nach einem PortScan ermittel- und angreifbar.
Java Servlets laufen als Anwendung auf dem Server (z.B. mit Tomcat etc.), womit dann mit einem Localhost-Zugriff auch der tatsächliche Webserver erreichbar wäre.

gentoo
2007-09-12, 13:17:42
Wie wärs mit Port Knocking (http://en.wikipedia.org/wiki/Port_knocking) und einem anderen SSH-Port als 22 (gut sind ports > 1024).

Das Problem am servlet ist, daß du zumindest eine ssl-verschlüsselte seite verwenden solltest um sniffing zu verhindern.

lg,
gentoo

Agent_no1
2007-09-12, 13:38:26
Über PortKnocking hatte ich auch schon nachgedacht.
Da PortKnocking aber noch nicht für den produktiven Einsatz geeignet ist und zudem das letzte Update über 2 Jahre zurückliegt, wollte ich davon erstmal absehen.

Darüber hinaus haben wir hier ein einmal eine Firewall direkt an der Front sowie eine direkt auf dem Ziehlhost wohin der SSH-Connect stattfinden soll. In diesem Fall müssten wir dann zwei Firewallregelsätze entsprechend anpassen oder zwei getrennte PortKnocking-Sequenzen ausführen lassen.

Der Hauptgedanke liegt für mich darin, dass ich lediglich Port 80 und 443 auf dem Zielhost freigebe (welche für den Verwendungszweck ohnehin offen sein müssen) und darüber hinaus keine weiteren Ports an die Front leite.

Die Verwendung von SSL stand für mich bereits im vornherein fest. :)

Grüße
Agent_no1