| View previous topic :: View next topic |
| Author |
Message |
nic0000
l33t
Joined: 25 Sep 2005
Posts: 658
|
 Posted: Sun Mar 19, 2006 5:57 pm Post subject: Verteiltes Netzwerk mit SSH oder lieber doch mit openVPN? |
 |
|
Moin, Moin
Folgendes Problem:
Ich warte mehre Gentoo-Workstations über das Internet mit SSH. Die Workstations sind in der Regel hinter DSL-Routern welche über DynDNS sich wiederfinden lassen.
Die Workstations können dank Gentoo super verwaltet werden, aber die Router sind grausam und unterliegen häufig sogar nicht meinen Einfluß (Alles Privatpersonen, Wohngemeinschaften, Hetrogene Netzwerke mit vielen DAUs).
Es passiert schon mal, daß ich vorbeifahren muss um den Router wieder richtigzustellen.
Wie kann ich das jetzt anders machen?
Meine Idee ist es jetzt, ein umgekehrten Verbindungsaufbau zu machen. Die Workstations melden sich bei mir bzw. einen Server im Netz.
a)
Ich habe von SSH nicht so viel Ahnung aber ich schätze das es so etwas kann.
b)
OpenVPN kann das bestimmt, ich weiß sogar in etwa wie.
Hat irgendjemand Erfahrung mit so etwas?
Hat jemand Links, Howtos, oder Configs für mich?
Was ist eurer Meinung der bessere Weg?
Wie sieht es mit Serverlast und Overhead aus?
Es sollen in der Zukunft hunderte bis tausende Workstations werden.
Danke und viele
_________________
grüße
nico |
|
| Back to top |
|
 |
Deever
Veteran
Joined: 06 Jul 2002
Posts: 1354
Location: Zürich / Switzerland
|
| Posted: Sun Mar 19, 2006 8:40 pm Post subject: |
|
|
In deinem Falle würde ich das VPN-Feature der neueren OpenSSH-Versionen ausprobieren, damit experimentiert habe ich selbst allerdings noch nicht.
Gruß,
/dev |
|
| Back to top |
|
|
nic0000
l33t
Joined: 25 Sep 2005
Posts: 658
|
| Posted: Sun Mar 19, 2006 9:31 pm Post subject: |
|
|
| Deever wrote: | | In deinem Falle würde ich das VPN-Feature der neueren OpenSSH-Versionen ausprobieren, damit experimentiert habe ich selbst allerdings noch nicht. |
Danke für den Hinweis, das wusste ich noch gar nicht.
Ist schon schon natürlich im Portage 
_________________
grüße
nico |
|
| Back to top |
|
|
slick
Bodhisattva
Joined: 20 Apr 2003
Posts: 3495
|
| Posted: Mon Mar 20, 2006 7:12 am Post subject: Re: Verteiltes Netzwerk mit SSH oder lieber doch mit openVPN |
|
|
| nic0000 wrote: | | Meine Idee ist es jetzt, ein umgekehrten Verbindungsaufbau zu machen. Die Workstations melden sich bei mir bzw. einen Server im Netz. |
Ich gehe davon aus der Server bei dem sich die anderen "anmelden" sollen befindet sich außerhalb des LANs. Von daher gibt es auch eine andere Möglichkeit, mit einer Verbindung alle zu erreichen, allerdings hat das nichts mit "umgekehrt" zu tun.
Nehmen wir an der "zentrale" Server heißt S, die anderen Maschinen M1 und M2 und Dein Client C.
Du sorgst einfach beim Verbindungsaufbau zu S dafür das ein Portforwarding von M1 zu C über S stattfindet. Es bedingt natürlich das S M1 auflösen bzw. erreichen kann. Damit hast Du dann mit einer Verbindung Verbindungen zu den anderen Maschinen geschaffen und kannst einfach darauf zugreifen:
| Code: | # bau einen Portforward von M1:22 nach Client(localhost):2022, sowie von M2:22 nach Client(localhost):2023 auf
# beides über S
ssh -L 2022:M1:22 -L 2023:M2:22 S
# jetzt connecte M1 (andere Console, da shell auf S nicht benötigt wird)
ssh -p 2022 localhost |
Evt. bekommst Du anfangs etwas Ärger weil ssh meckert das die Keys in ~/.ssh/known_hosts nicht passen, da hilft es die Keys aller Maschinen (unter localhost) manuell in die known_hosts einzutragen.
Vorteile:
- Du brauchst keine weitere Software oder andere komplexe Einrichtung.
- Eine Verbindung zu S reicht um auf alle anderen zuzugreifen
Nachteile:
- Traffic nach M1 läuft über S
- andere Maschinen (M1, M2) müssen von S aus erreichbar sein
- zum Zugang auf M1 muss Verbindung zu S bestehen
- Maschinen (M1,M2) können kein port knocking benutzen, also (ssh-) Port muss offen sein
Mit autossh läßt sich aber z.B. eine permanente Verbindung (zu S) aufrecht erhalten was alles etwas vereinfacht.
Klingt vielleicht alles im ersten Moment kompliziert, aber wenns einmal läuft merkt man kaum den Unterschied.
http://www.securityfocus.com/infocus/1816
http://www.ssh.com/support/documentation/online/ssh/adminguide/32/Port_Forwarding.html
| Quote: | | Es sollen in der Zukunft hunderte bis tausende Workstations werden. |
Ok, für sowas würde ich das nicht machen, allerdings bedingt ein dauerhaftes VPN (o.ä.) das die Zugangsdaten zu den Maschinen M1 und M1 auf S hinterlegt sind bzw. die Daten zu S auf M1 und M2, was ich nicht für besonders sicher halte. Von daher ist das Portforwarding meines Erachtens das sicherste, weil es ja das Passwort/den Key erst beim Zugriff benötigt.
EDIT: muss heissen ssh -L ... statt ssh -R ..., korrigiert |
|
| Back to top |
|
|
nic0000
l33t
Joined: 25 Sep 2005
Posts: 658
|
| Posted: Mon Mar 20, 2006 1:50 pm Post subject: Re: Verteiltes Netzwerk mit SSH oder lieber doch mit openVPN |
|
|
| slick wrote: |
Vorteile:
- Du brauchst keine weitere Software oder andere komplexe Einrichtung.
- Eine Verbindung zu S reicht um auf alle anderen zuzugreifen |
zu 1
Das ist natürlich in meinem Sinne. KISS
zu 2
Das ist aber bei der klassischen VPN Lösung selbstverständlich auch möglich.
| slick wrote: | Nachteile:
- Traffic nach M1 läuft über S
- andere Maschinen (M1, M2) müssen von S aus erreichbar sein
- zum Zugang auf M1 muss Verbindung zu S bestehen
- Maschinen (M1,M2) können kein port knocking benutzen, also (ssh-) Port muss offen sein |
zu 1
Nunja, das muß in kauf genommen werden, Sicherheit kostet nun mal.
zu 2
Das ist das eigentliche Problem, denn die Clients stehen häufig hinter Routern welche nicht in meiner Verwaltung stehen. Das es aber simple NAT Router sind kann von "innen" eine Verbindung zu S aufgebaut werden. Das meinte ich mit "umgekehrt".
zu 3
Siehe 2
zu 4
Naja, das versuche ich auch zu umgehen in dem die Verbindung von innen nach außen aufgebaut wird.
| slick wrote: | | Mit autossh läßt sich aber z.B. eine permanente Verbindung (zu S) aufrecht erhalten was alles etwas vereinfacht. |
Das ist ein guter Tipp, das habe ich mir sofort angeschaut
| slick wrote: |
Klingt vielleicht alles im ersten Moment kompliziert, aber wenns einmal läuft merkt man kaum den Unterschied. |
Das ist aber alles kompliziert  Egal was ich anfasse, es artet in Arbeit aus.
| slick wrote: | | Quote: | | Es sollen in der Zukunft hunderte bis tausende Workstations werden. |
Ok, für sowas würde ich das nicht machen, allerdings bedingt ein dauerhaftes VPN (o.ä.) das die Zugangsdaten zu den Maschinen M1 und M1 auf S hinterlegt sind bzw. die Daten zu S auf M1 und M2, was ich nicht für besonders sicher halte. |
Naja, das mit den Zugangsdaten kann genauso gehandhabt werden wie mit bei deiner Lösung:
Hier paar Keyfacts:
Es gibt in openVPN (und davon rede ich wenn ich VPN meine), eine ganze reihe von Features um eben in sehr großen Netzwerken einzelne Roadwarriors an einen Server oder Netzwerk anzuschließen.
-Automatischer VPN aufbau von Mx zu S
-Keepalive der Verbindung zu S
-VPN aufbau zum S auf Grundlage von individuellen! Zertifikaten auf Mx.
-Zentrale Steuerung des Routing innerhalb des VPN
Dabei ist zwischen M1 und S zwar ein Netzwerk, welches wiederum auf beiden Seiten via Firewall dicht gemacht werden kann.
Mehr Sicherheit? Versuchen wir mal:
Eventueller Einsatz von Portnocking auf Client um SSH zu schützen.
Sicherheitslücken im Konzept?
Der M1 wird kompromittiert:
Ein Angreifer hat jetzt ein Zertifikat und damit die Möglichkeit sich mit dem Server zu verbinden und steht wie auch ohne VPN vor einer Wand (bzw. wie Außen).
Angriffsversuche welche registriert werden, können eindeutig zugeordnet werden -> Zertifikat wird entzogen ->Patient ist draußen (live is brutal)
Der S wird kompromittiert:
Der Angreifer hat jetzt so oder so zu viele Möglichkeiten 
Jetzt kommt deine Methode sehr gut zum Zuge.
VPN um den Tunnel von Mx zu S zu graben (Wobei VPN eventuell sich durch die neueren SSH Versionen ersetzen läßt.)
SSH um Portforwarding zwischen C <-> S <-> Mx zu machen.
Leider gibt es da ein klitzekleines Problem
Ich sollte jetzt vielleicht paar mehr Informationen rüberwachsen lassen:
Ziel sollte es sein, das der Admin sich zentral auf dem Server einloggen und von dort aus via screen eine Verbindung zum Mx aufbauen kann. Diese Verbindung S <-> Mx soll geloggt werden. Die Möglichkeit sich direkt auf Mx zu loggen wird nicht gegeben.
Wieso so etwas?
Das habe ich hier in diesem Thread angesprochen https://forums.gentoo.org/viewtopic-t-419612.html
Eventuelle Einwände bitte auch gleich dorthin posten.
Wie kann das jetzt gelöst werden?
1)
Aufs loggen verzichten.
2)
Server als Kritischen Punkt belassen.
Beides also auf kosten der Sicherheit und damit inakzeptabel.
Mögliche Idee?
Suggestion
Die SSH Schlüssel für Mx liegen verschlüsselt auf S und werden nur bei bedarf entschlüsselt.
Aufwand<->Nutzen
Verbessert die Situation bisschen aber nicht wirklich.
Bei deiner Methode ist wiederum der (Admin) Client das Problem.
Hmmm...
Irgendwie sollte ich Knobelaufgaben entwickeln, scheint ein verkanntes Talent von mir zu sein...
_________________
grüße
nico |
|
| Back to top |
|
|
Anarcho
Advocate
Joined: 06 Jun 2004
Posts: 2970
Location: Germany
|
| Posted: Mon Mar 20, 2006 3:45 pm Post subject: |
|
|
Ohne alles gelesen zu haben:
Ich betreue einen Server der hinter einem Zyxel (Kotz) Router steht. In diesem habe ich zwar Portforwarding nach Anleitung eingerichtet, aber es geht nicht.
Der Server verbindet sich nun per OpenVPN mit meinem Heimserver und ein Cron-Job überprüft die Verbindung und baut diese neu auf falls sie verloren ist.
Dies passiert natürlich weil bei Rechner unter der 24h DSL Disconnect leiden.
Das funktioniert sehr gut.
_________________
...it's only Rock'n'Roll, but I like it! |
|
| Back to top |
|
|
slick
Bodhisattva
Joined: 20 Apr 2003
Posts: 3495
|
| Posted: Mon Mar 20, 2006 4:20 pm Post subject: |
|
|
| Quote: | | Der Server verbindet sich nun per OpenVPN mit meinem Heimserver und ein Cron-Job überprüft die Verbindung und baut diese neu auf falls sie verloren ist. Dies passiert natürlich weil bei Rechner unter der 24h DSL Disconnect leiden. |
Installiere auf dem Server knockd und lass in der ip-up des Heimservers ein Klopfzeichen an den Server los. So kann er sich fast verzögerungsfrei neu beim Heimserver anmelden. |
|
| Back to top |
|
|
slick
Bodhisattva
Joined: 20 Apr 2003
Posts: 3495
|
| Posted: Mon Mar 20, 2006 4:34 pm Post subject: Re: Verteiltes Netzwerk mit SSH oder lieber doch mit openVPN |
|
|
| nic0000 wrote: | | Ziel sollte es sein, das der Admin sich zentral auf dem Server einloggen und von dort aus via screen eine Verbindung zum Mx aufbauen kann. Diese Verbindung S <-> Mx soll geloggt werden. Die Möglichkeit sich direkt auf Mx zu loggen wird nicht gegeben. |
Also wenn ich das richtig verstanden habe:
Clients conntecten S und sollen dann zu Mx durchgereicht werden. Alles was Client auf Mx anstellt soll geloggt werden. Korrekt?
Dann ganz blöde Idee mit viel Overhead, obs klappt weiß ich nicht. Also Client connectet S, S baut eine Telnet(!) Session durch einen ssh-Tunnel zu Mx auf. Client bekommt die Telnetsession wiederrum durch seinen ssh-Tunnel (zu S) weitergereicht. Sollte theoretisch funktionieren. Zumindest kannst Du dann mit einem einfachen sniffer an S alles loggen, und zwar nur an S, da die externe Kommunikation zu Mx oder Client über Tunnel läuft. |
|
| Back to top |
|
|
Anarcho
Advocate
Joined: 06 Jun 2004
Posts: 2970
Location: Germany
|
| Posted: Mon Mar 20, 2006 4:43 pm Post subject: |
|
|
| slick wrote: | | Quote: | | Der Server verbindet sich nun per OpenVPN mit meinem Heimserver und ein Cron-Job überprüft die Verbindung und baut diese neu auf falls sie verloren ist. Dies passiert natürlich weil bei Rechner unter der 24h DSL Disconnect leiden. |
Installiere auf dem Server knockd und lass in der ip-up des Heimservers ein Klopfzeichen an den Server los. So kann er sich fast verzögerungsfrei neu beim Heimserver anmelden. |
Das geht ja leider nicht weil ich nicht aktiv an den Server ran kann, da portforwarding nicht klappt.
Eigentlich sollte OpenVPN auch erkennen das die Verbindung weg ist und neu verbinden, klappt aber noch nicht so richtig.
Da ich nur selten an den Server muss reicht es mir wenn spätestens nach 5 min die Verbindung wieder steht.
_________________
...it's only Rock'n'Roll, but I like it! |
|
| Back to top |
|
|
nic0000
l33t
Joined: 25 Sep 2005
Posts: 658
|
| Posted: Mon Mar 20, 2006 4:47 pm Post subject: |
|
|
| slick wrote: | | Quote: | | Der Server verbindet sich nun per OpenVPN mit meinem Heimserver und ein Cron-Job überprüft die Verbindung und baut diese neu auf falls sie verloren ist. Dies passiert natürlich weil bei Rechner unter der 24h DSL Disconnect leiden. |
Installiere auf dem Server knockd und lass in der ip-up des Heimservers ein Klopfzeichen an den Server los. So kann er sich fast verzögerungsfrei neu beim Heimserver anmelden. |
Ich glaube du hast sein Problem nicht richtig verstanden. War wohl eine nette Party gestern, oder Slick?
Das Problem sind in der Regel die Router.
Client ---------- Inet ---------- |Router ----- Server
Client >----------> Inet >----------> |Router ----- Server
geht nicht wegen geschlossener Ports. (Bei Anarcho ist es Zyxel der sich nicht vernünftig konfigurieren lässt, bei mir sind es verschiedene Router die ich nicht anfassen will bzw. kann.)
Client <----------< Inet <----------<|<Router <-----< Server
Das geht, denn die meisten Firewalls lassen Traffic aus dem Lan raus.
Daher nutzt ihm knockd auch nichts.
Daher gräbt Anarcho einen Tunnel vom Server zum Client um dann Zugriff auf ihn zu bekommen.
@Anarcho es gibt da eine "keepalive" Funktion in openVPN welche den Tunnel permanent offen hält. Das macht den Cronjob überflüssig und klappt sehr gut. Wir verbinden unsere Heim-Server so untereinander um uns gegenseitig den Upstream zu rauben
_________________
grüße
nico |
|
| Back to top |
|
|
Anarcho
Advocate
Joined: 06 Jun 2004
Posts: 2970
Location: Germany
|
| Posted: Mon Mar 20, 2006 4:53 pm Post subject: |
|
|
Das mit dem Keep-alive ist mir bekannt (und habe ich auch schon drin, soweit ich weiss).
Das Problem ist dann nur das sich ja die IP ändert und dann hat er irgendwie probleme.
Vielleicht liegt das dann auch wieder an dem Zyxelschrott.
Jedenfalls hatte ich keine Lust da gross rumzuprobieren und 10 Zeilen bash-script gingen dann doch einfach schneller...
_________________
...it's only Rock'n'Roll, but I like it! |
|
| Back to top |
|
|
slick
Bodhisattva
Joined: 20 Apr 2003
Posts: 3495
|
| Posted: Mon Mar 20, 2006 9:00 pm Post subject: |
|
|
| nic0000 wrote: | | Ich glaube du hast sein Problem nicht richtig verstanden. |
Joar... jetzt wo Du das so sagst...
| nic0000 wrote: | | War wohl eine nette Party gestern, oder Slick? |
Jein... war gestern auf der Beauty, das haut den stärksten Kerl um (bei ~90% Frauenanteil...  )
Habe übrigens das Gefühl ihr habt mein eines Post überlesen, oder wars auch sowas von daneben? |
|
| Back to top |
|
|
nic0000
l33t
Joined: 25 Sep 2005
Posts: 658
|
| Posted: Mon Mar 20, 2006 9:49 pm Post subject: Re: Verteiltes Netzwerk mit SSH oder lieber doch mit openVPN |
|
|
Oh man, ich habe das post gar nicht mitgekriegt *peinlich*
| slick wrote: | | Clients conntecten S und sollen dann zu Mx durchgereicht werden. Alles was Client auf Mx anstellt soll geloggt werden. Korrekt? |
Korrekt.
| slick wrote: | | Dann ganz blöde Idee mit viel Overhead, obs klappt weiß ich nicht. Also Client connectet S, S baut eine Telnet(!) Session durch einen ssh-Tunnel zu Mx auf. Client bekommt die Telnetsession wiederrum durch seinen ssh-Tunnel (zu S) weitergereicht. Sollte theoretisch funktionieren. Zumindest kannst Du dann mit einem einfachen sniffer an S alles loggen, und zwar nur an S, da die externe Kommunikation zu Mx oder Client über Tunnel läuft. |
Also ich finde die Idee durchaus gut brauchbar. Werde mal darüber Meditieren.
Generell ist das einfach keine 0815 Allertagsaufgabe, von daher ist Kreativität gebraucht.
_________________
grüße
nico |
|
| Back to top |
|
|
think4urs11
Bodhisattva
Joined: 25 Jun 2003
Posts: 6659
Location: above the cloud
|
| Posted: Mon Mar 20, 2006 11:08 pm Post subject: |
|
|
Ich hoffe ich hab alles richtig verstanden/im Kopf...
- du möchtest über einen zentralen Server (S) eine Art Managment-Gateway zu Clients (C) hinter NAT-Routern bauen.
- dazu sollen diese Clients 'on demand' eine Verbindung zum Mgmt.-GW aufbauen
- du (ein Admin) verbindet sich dann von seiner Workstation (A) zum GW und bekommt über diesen eine Shell auf dem Client um zu administrieren
- der zentrale Server ist primär dafür gedacht um eine Sammelstelle für Sessionlogs zu haben
richtig?
Wenn ja, dann ....
1. C baut via ssh eine Verbindung zu S auf
2. dein Klient ruft einen Admin an damit ihm geholfen wird
3. A baut via ssh eine Verbindung zu S auf
4. die Verbindung aus 3 wird 'durchgeschaltet' auf C
zu 1. hier sollte ein ssh forwarding aufgebaut werden das *von S* einen Port zu C rückwärts weiterleitet mit Ziel C:<sshport>
weiterhin wird bei diesem Verbindungsaufbau eine Screensession *auf S* gestartet mit Sessionname=Klient und username=Klient
Der Trick ist nun *innerhalb* dieser Screensession direkt einen ssh 'rückwärts' zu C aufzubauen, eben als ssh remotesupport@localhost:<port für diesen Klienten>. Um das automatisieren zu können solltest du einen pubkey ohne Passphrase generieren. Außerdem sollte (auf S) die host key verification (wg. der wechselnden IP von C) ausgeschaltet werden.
weiterhin wird die Session mit aktiviertem Logging gestartet und sofort wieder detached.
um es nicht zu kompliziert zu machen solltest du jedem Klienten *fix* einen eigenen Port auf S zuweisen (oberhalb 1024 dann brauchts keine root rechte)
damit das weitere sauber funktioniert muß screen +s gesetzt sein
zu 3. Admin bekommt den Anruf und baut daraufhin eine Remotesupportsession zu S auf mit seiner eigenen Userid auf S
Admin landet in einer ganz normalen Shell
Admin tippt screen -rd <Klient>
Dadurch landet Admin in einer Screensession die auf C angemeldet ist. Ein su - und das Administrieren kann beginnen.
Wenn Admin fertig ist mit administrieren detached er die Screensession.
Voraussetzung:
Bei jedem deiner Klienten muß ein User 'remotesupport' existieren
Auf dem Server muß für jeden Klienten ein eigener User existieren.
Für jeden Klienten muß ein eigener, eindeutiger 'rückwärts-support-ssh-tunnel-port' definiert sein.
Je nach Paranoia kannst du das ganze noch so gestalten das die Logfiles der Screensessions in einem Verzeichnis landen in dem zwar deine Klienten Schreibrechte haben, die einzelnen Admins aber nicht.
Das ganze klingt so verwickelt das es glatt funktionieren könnte.
_________________
Nothing is secure / Security is always a trade-off with usability / Do not assume anything / Trust no-one, nothing / Paranoia is your friend / Think for yourself |
|
| Back to top |
|
|
nic0000
l33t
Joined: 25 Sep 2005
Posts: 658
|
| Posted: Tue Mar 21, 2006 12:15 am Post subject: |
|
|
Da es schon spät ist werde ich nicht das ganze jetzt kommentieren, hoffentlich verzeihst du mir das jetzt. Ich weiß die viele Mühe trotzdem zu schätzen.
| Think4UrS11 wrote: | Ich hoffe ich hab alles richtig verstanden/im Kopf...
- du möchtest über einen zentralen Server (S) eine Art Managment-Gateway zu Clients (C) hinter NAT-Routern bauen.
- dazu sollen diese Clients 'on demand' eine Verbindung zum Mgmt.-GW aufbauen
- du (ein Admin) verbindet sich dann von seiner Workstation (A) zum GW und bekommt über diesen eine Shell auf dem Client um zu administrieren
- der zentrale Server ist primär dafür gedacht um eine Sammelstelle für Sessionlogs zu haben
richtig?
|
Perfekt. Ich habe es gleich so ins Pflichtenheft übernommen
| Think4UrS11 wrote: | Wenn ja, dann ....
1. C baut via ssh eine Verbindung zu S auf
2. dein Klient ruft einen Admin an damit ihm geholfen wird
3. A baut via ssh eine Verbindung zu S auf
4. die Verbindung aus 3 wird 'durchgeschaltet' auf C
|
Das ist der Plan...
Jetzt muss ich mich aber zusammenreißen...
[...]
Nee, das ist zu Hart für meinen Kopf um die Uhrzeit. Das muß ich mir mal morgen angucken.
ehehe, und ich dachte ich entwickle verzwickte Lösungswege. Manchmal bin ich einfach zu Naiv.
Gute N8
_________________
grüße
nico |
|
| Back to top |
|
|
think4urs11
Bodhisattva
Joined: 25 Jun 2003
Posts: 6659
Location: above the cloud
|
| Posted: Tue Mar 21, 2006 6:54 am Post subject: |
|
|
| nic0000 wrote: | | Da es schon spät ist werde ich nicht das ganze jetzt kommentieren, hoffentlich verzeihst du mir das jetzt. Ich weiß die viele Mühe trotzdem zu schätzen. |
Null Problemo, ich will mir das auch gerade nochmal durchlesen ob das ganze überhaupt Sinn macht. Wie du schon sagst es war spät.
_________________
Nothing is secure / Security is always a trade-off with usability / Do not assume anything / Trust no-one, nothing / Paranoia is your friend / Think for yourself |
|
| Back to top |
|
|
nic0000
l33t
Joined: 25 Sep 2005
Posts: 658
|
| Posted: Tue Mar 21, 2006 12:51 pm Post subject: |
|
|
So jetzt versuch ich es noch mal.
| Think4UrS11 wrote: |
zu 1. hier sollte ein ssh forwarding aufgebaut werden das *von S* einen Port zu C rückwärts weiterleitet mit Ziel C:<sshport> |
Das verstehe ich nicht. Kannst du mir das genauer Erklären oder auf Doku verweisen. Ist das eine normale Prozedur?
Ich verstehe das nur so:
Theorie soll sein:
C baut Tunnel zu S auf (Tunnel A). S baut einen Tunnel zu C:<sshport> innerhalb des Tunnel A.
Habe ich wenigstes das richtig verstanden?
| Think4UrS11 wrote: | | weiterhin wird bei diesem Verbindungsaufbau eine Screensession *auf S* gestartet mit Sessionname=Klient und username=Klient |
Das ist gut, soweit alles klar.
| Think4UrS11 wrote: | | Der Trick ist nun *innerhalb* dieser Screensession direkt einen ssh 'rückwärts' zu C aufzubauen, eben als ssh remotesupport@localhost:<port für diesen Klienten>. |
Das ist genial.
| Think4UrS11 wrote: | | Um das automatisieren zu können solltest du einen pubkey ohne Passphrase generieren. Außerdem sollte (auf S) die host key verification (wg. der wechselnden IP von C) ausgeschaltet werden. |
Ok, dann geschieht das ohne Nutzer Intervention.
| Think4UrS11 wrote: | | weiterhin wird die Session mit aktiviertem Logging gestartet und sofort wieder detached. |
Das ist gut.
| Think4UrS11 wrote: | | um es nicht zu kompliziert zu machen solltest du jedem Klienten *fix* einen eigenen Port auf S zuweisen (oberhalb 1024 dann brauchts keine root rechte) |
OK, naja, noch sind es ja nicht 10 Tausende 
| Think4UrS11 wrote: | | damit das weitere sauber funktioniert muß screen +s gesetzt sein |
Wegen Multimode, oder?
| Think4UrS11 wrote: | zu 3. Admin bekommt den Anruf und baut daraufhin eine Remotesupportsession zu S auf mit seiner eigenen Userid auf S
Admin landet in einer ganz normalen Shell |
DAS kriege ich hin
| Think4UrS11 wrote: | Admin tippt screen -rd <Klient>
Dadurch landet Admin in einer Screensession die auf C angemeldet ist. Ein su - und das Administrieren kann beginnen.
Wenn Admin fertig ist mit administrieren detached er die Screensession. |
OK, verstanden.
| Think4UrS11 wrote: | Voraussetzung:
Bei jedem deiner Klienten muß ein User 'remotesupport' existieren
Auf dem Server muß für jeden Klienten ein eigener User existieren.
Für jeden Klienten muß ein eigener, eindeutiger 'rückwärts-support-ssh-tunnel-port' definiert sein. |
OK, so weit Klar und machbar (denke ich).
| Think4UrS11 wrote: | | Je nach Paranoia kannst du das ganze noch so gestalten das die Logfiles der Screensessions in einem Verzeichnis landen in dem zwar deine Klienten Schreibrechte haben, die einzelnen Admins aber nicht. |
Ja, das ist gut.
| Think4UrS11 wrote: | | Das ganze klingt so verwickelt das es glatt funktionieren könnte. |
ehehe
Schema:
1)Aufbau des SSH Tunnels C zu S
2)Aufbau des Forwarding-Tunnels S:<clientport> zu C innerhalb des anderen Tunnels.
3)Starten einer Screeen-Session mit Sessionname=Klient und username=Klient auf S
4)Innerhalb dieser Screen-Session soll automatisch einer SSH remotesupport@localhost:<clientport> Verbindung S zu C mit pubkey gestartet werden.
5)Die Screeen-Session startet loggin und detacht selbstständig.
6-X)Der Admin loggt sich mit seinem Account auf S und retacht die <Klient> Session mit "screen -rd <Klient>"
ist somit lokal auf C und kann arbeiten etc.
Fragen
Habe ich das jetzt richtig verstanden?
_________________
grüße
nico |
|
| Back to top |
|
|
Anarcho
Advocate
Joined: 06 Jun 2004
Posts: 2970
Location: Germany
|
| Posted: Tue Mar 21, 2006 1:11 pm Post subject: |
|
|
Also ich finde das ist viel zu kompliziert.
Ich würde das tatsächlich per OpenVPN machen:
Ein Server mit OpenVPN.
In der Config NICHT client-to-client setzen, damit die einzelnen Rechner sich nicht einfach gegenseitig sehen können.
Dann könnte man noch nen eigenen DNS Server auf dem Server aufsetzen der eventuell sogar dynamisch per DHCP IP-Adressen vergibt und den entsprechenden Namen auflöst.
Die Clients verbinden sich alle per VPN, entweder permanent oder auf Knopfdruck.
Du kannst dich dann per SSH auf den server verbinden und von dort aus weiter zu den Clients oder, falls client-to-client doch OK wäre, direkt vom Heimrechner per VPN.
Das ganze hat dann ein paar Vorteile:
- du kannst immer standardports verwenden
- du kannst nicht nur per SSH auf den Rechner zugreifen sondern auch mit jedem anderen Protokoll/an jeden anderen Port ohne weitere Einrichtungen
- sehr einfache Einrichtung
- per CRL kannst du auch sehr einfach rechner aus dem Verband rauswerfen
- sehr einfach neue Rechner integrieren
_________________
...it's only Rock'n'Roll, but I like it! |
|
| Back to top |
|
|
nic0000
l33t
Joined: 25 Sep 2005
Posts: 658
|
| Posted: Tue Mar 21, 2006 1:24 pm Post subject: |
|
|
| Anarcho wrote: | Also ich finde das ist viel zu kompliziert.
Ich würde das tatsächlich per OpenVPN machen:
|
Naja, der Schritt 1 eventuell auch 2 (bin mir nicht sicher) kann durch VPN ersetzt werden, aber der Rest sieht sehr gut aus.
_________________
grüße
nico |
|
| Back to top |
|
|
think4urs11
Bodhisattva
Joined: 25 Jun 2003
Posts: 6659
Location: above the cloud
|
| Posted: Tue Mar 21, 2006 4:40 pm Post subject: |
|
|
| nic0000 wrote: | | Think4UrS11 wrote: | | damit das weitere sauber funktioniert muß screen +s gesetzt sein |
Wegen Multimode, oder? |
Exakt
| nic0000 wrote: | Schema:
1)Aufbau des SSH Tunnels C zu S
2)Aufbau des Forwarding-Tunnels S:<clientport> zu C innerhalb des anderen Tunnels.
3)Starten einer Screeen-Session mit Sessionname=Klient und username=Klient auf S
4)Innerhalb dieser Screen-Session soll automatisch einer SSH remotesupport@localhost:<clientport> Verbindung S zu C mit pubkey gestartet werden.
5)Die Screeen-Session startet loggin und detacht selbstständig.
6-X)Der Admin loggt sich mit seinem Account auf S und retacht die <Klient> Session mit "screen -rd <Klient>"
ist somit lokal auf C und kann arbeiten etc.
Fragen
Habe ich das jetzt richtig verstanden? |
Yepp.
1-5 müßte sich (theoretisch) vom Klienten mit einer einzigen ssh Befehlszeile machen lassen
| Anarcho wrote: | | - du kannst immer standardports verwenden |
ok, agreed. Aber mit ein bischen Planung kein großes Problem
| Anarcho wrote: | | - du kannst nicht nur per SSH auf den Rechner zugreifen sondern auch mit jedem anderen Protokoll/an jeden anderen Port ohne weitere Einrichtungen |
Das ist eindeutig pro OpenVPN, kein Zweifel. Kommt eben auf die exakten Anforderungen der Klienten an.
Gerüchteweise haben manche Windows im Einsatz, dann müßte zumindest ein Tunnel auf 3389 mit bedacht werden
| Anarcho wrote: | | - per CRL kannst du auch sehr einfach rechner aus dem Verband rauswerfen |
public key 'Klient' aus Server:~/.ssh/authorized_keys löschen ist auch nicht weiter komplex
Wie geht OpenVPN mit sich überlappenden Netzen um?
Kann ja gut sein das Klient A und Klient B im LAN jeweils z.B. 192.168.1.0/24 fahren. Könnte dann bei beiden auch parallel administriert werden?
_________________
Nothing is secure / Security is always a trade-off with usability / Do not assume anything / Trust no-one, nothing / Paranoia is your friend / Think for yourself
Last edited by think4urs11 on Tue Mar 21, 2006 4:45 pm; edited 1 time in total |
|
| Back to top |
|
|
Anarcho
Advocate
Joined: 06 Jun 2004
Posts: 2970
Location: Germany
|
| Posted: Tue Mar 21, 2006 4:44 pm Post subject: |
|
|
Nun, das OpenVPN Subnetz muss man sowieso festlegen. Ich verwende für OpenVPN immer 10.x.x.x, aber auch jedes andere Subnetz ist möglich.
Dann nimmt man einfach ein sehr ungewöhnliches und dann dürfte das kein grösseres Problem darstellen. Jeder Rechner bekommt dann an seinem tap-device ne IP aus dem Subnetz.
_________________
...it's only Rock'n'Roll, but I like it! |
|
| Back to top |
|
|
think4urs11
Bodhisattva
Joined: 25 Jun 2003
Posts: 6659
Location: above the cloud
|
| Posted: Tue Mar 21, 2006 4:55 pm Post subject: |
|
|
Ok, d.h. stark vereinfacht legt man pro Klient ein eigenes 10.x.y.z/24 Segment fest anstatt wie bei der SSH-Geschichte einen Port auf dem Server.
Vorteil bei OpenVPN ist die Flexibilität.
Nachteil ist das nicht vorhandene Logging; dazu muß dann auch wieder auf screen zurückgegriffen werden.
(bashlogger ist nur eine halbe Lösung da es ja nur bash loggt; nach Wechsel in eine andere Shell ist Ende mit log)
Was in beiden Fällen nicht geht ist alles außer ssh zu protokollieren außer über tcpdump - und das will niemand auswerten/überwachen.
@nico:
Werd mal spezifischer dann können wir da gerne ein entsprechendes Konzept ausarbeiten (Werkvertrag, Dienstleistung, etc.)
_________________
Nothing is secure / Security is always a trade-off with usability / Do not assume anything / Trust no-one, nothing / Paranoia is your friend / Think for yourself |
|
| Back to top |
|
|
Anarcho
Advocate
Joined: 06 Jun 2004
Posts: 2970
Location: Germany
|
| Posted: Tue Mar 21, 2006 5:05 pm Post subject: |
|
|
| Think4UrS11 wrote: | Ok, d.h. stark vereinfacht legt man pro Klient ein eigenes 10.x.y.z/24 Segment fest anstatt wie bei der SSH-Geschichte einen Port auf dem Server.
Vorteil bei OpenVPN ist die Flexibilität.
Nachteil ist das nicht vorhandene Logging; dazu muß dann auch wieder auf screen zurückgegriffen werden.
(bashlogger ist nur eine halbe Lösung da es ja nur bash loggt; nach Wechsel in eine andere Shell ist Ende mit log)
Was in beiden Fällen nicht geht ist alles außer ssh zu protokollieren außer über tcpdump - und das will niemand auswerten/überwachen.
@nico:
Werd mal spezifischer dann können wir da gerne ein entsprechendes Konzept ausarbeiten (Werkvertrag, Dienstleistung, etc.) |
Nein, man legt 1 Subnetz fest und jeder Client bekommt eine IP aus diesem Subnetz. Dadurch befinden sich alle Clients virtuell im gleichen Subnetz.
Will man mehrere getrennte Subnetze kann man das über unterschiedliche subnetzmasken machen (unschön) oder einfach mehrere OpenVPN Instanzen laufen lassen.
Wir haben hier eine instanz für admins und eine für externe die sich was vom webserver laden können (und sonst nichts dürfen). Diese liegen in Unterschiedlichen Subnetzen (10.8.0.0/24 und 10.5.0.0/24)
EDIT: Ich machs günstiger als Think4Ur11
_________________
...it's only Rock'n'Roll, but I like it! |
|
| Back to top |
|
|
nic0000
l33t
Joined: 25 Sep 2005
Posts: 658
|
| Posted: Tue Mar 21, 2006 5:46 pm Post subject: |
|
|
Netter Plasch, ich bin auch noch da!!
zum Thema spezifischer und Geld:
Das ist zur Zeit ein akademisches Projekt mit Freiwilligen in dem ich und noch paar andere arme Seelen unsere Freizeit seit über 2 Jahren reinstecken.
Es wird in der nächsten Zeit zu einem Verein umgebaut und soll stark wachsen, deshalb der ganze Stress mit dieser Frage usw.
Ziel des Vereins ist die Förderung von GNU/Linux und anderer OS Software im täglichen Einsatz.
Schwerpunkt sind Computer Einsteiger bzw. Anwender mit geringem Computer-Wissen.
Für diesen Personen-Kreis haben wir ein weitreichendes Schulungsangebot erstellt und bauen dieses kontinuierlich aus.
Die Workstations sind alle weitgehend identisch und haben KEIN M$ BS installiert.
Soll ich weiter erzählen oder seit ihr schon enttäuscht?
Wenn ihr Geld verdienen wollt dann bitte per PM eine Liste von Sachen die ihr könnt bzw. machen wollt.
Ich garantiere für nichts aber ich bekomme regelmäßig Anfragen zu Sachen die ich nicht kann bzw. _mir_ kein Spaß machen und werde dann an euch denken.
Wenn dann brauche ich ehrenamtliche Hilfe, denn die Kosten für dieses "Hobby" fahre nicht mal annährend rein. Glücklicher weise ist meine Frau genügsam _und_ geduldig.
Ansonsten würde ich euch gerne auf unsere Webseite verweisen, nur leider muß ich erst den Server & Domain mieten und dann noch einrichten
Wobei wir eigentlich schon wieder bei einer Reihe neuer Probleme sind da ich der einzige Admin bin.
So, jetzt könnt ihr weglaufen
_________________
grüße
nico |
|
| Back to top |
|
|
think4urs11
Bodhisattva
Joined: 25 Jun 2003
Posts: 6659
Location: above the cloud
|
| Posted: Tue Mar 21, 2006 7:00 pm Post subject: |
|
|
| nic0000 wrote: | Ziel des Vereins ist die Förderung von GNU/Linux und anderer OS Software im täglichen Einsatz.
Schwerpunkt sind Computer Einsteiger bzw. Anwender mit geringem Computer-Wissen.
Für diesen Personen-Kreis haben wir ein weitreichendes Schulungsangebot erstellt und bauen dieses kontinuierlich aus.
Die Workstations sind alle weitgehend identisch und haben KEIN M$ BS installiert.
Soll ich weiter erzählen oder seit ihr schon enttäuscht? |
Im Gegentum, bin beinahe schon begeistert! (ernstgemeint!)
| nic0000 wrote: | | Wenn ihr Geld verdienen wollt dann bitte per PM eine Liste von Sachen die ihr könnt bzw. machen wollt. ... |
| Anarcho wrote: | | Ich machs günstiger als Think4Ur11 |
Hose runter, Preise auf den Tisch
Ernsthaft. Ich hab schon nen leidlich gut bezahlten Job und das geniale ist das ich da praktisch für mein Hobby bezahlt werde. Was natürlich nicht heißt das ich das dadurch erworbene Wissen nicht bei sich bietender Gelegenheit nebenher in geldwerten Vorteil umzusetzen bereit bin.
Zeit ist halt immer so eine Sache... Rechenzentren haben die dumme Angewohnheit auf Privatleben exakt gar keine Rücksicht zu nehmen.
| nic0000 wrote: | | Glücklicher weise ist meine Frau genügsam _und_ geduldig. |
Hat die ne (hübsche, freie) Schwester mit Faible für EDVler? 
| nic0000 wrote: | | So, jetzt könnt ihr weglaufen |
Och naja das einzige was mich sehr effektiv zum Weglaufen bringen würde wär wenn du im realen Leben auch immer sooo bissig schaust wie dein Avatar
| Anarcho wrote: | | Nein, man legt 1 Subnetz fest und jeder Client bekommt eine IP aus diesem Subnetz. Dadurch befinden sich alle Clients virtuell im gleichen Subnetz. |
Das ist doch dann aber ein Client-to-Client oder? Dann müßte doch (dummstell) bei einem Klienten mit 2-x PC jeder einzelne PC jeweils eine gesonderte VPN-Session aufmachen, richtig?
Angenommen du willst über den Server direkt 'durchgreifen' auf die zu wartenden PCs würde doch eher etwas Sinn machen wie
10.0.1.0/24 - 'die Admins'
10.0.x.0/24 - je Klient eine C-Klasse (sollte reichen)
In Nortel-Sprache wäre sowas dann ein branchoffice-2-branchoffice VPN sprich kommend aus dem einen Tunnel kann ich auf Geräte im anderen Tunnel direkt über mein VPN-Gateway zugreifen das dann quasi nur noch als Router zwischen den Tunneln fungiert.
_________________
Nothing is secure / Security is always a trade-off with usability / Do not assume anything / Trust no-one, nothing / Paranoia is your friend / Think for yourself |
|
| Back to top |
|
|
|
Deutsches Forum (German) 
