# Verteiltes Netzwerk mit SSH oder lieber doch mit openVPN?

## nic0000

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

----------

## Deever

In deinem Falle würde ich das VPN-Feature der neueren OpenSSH-Versionen ausprobieren, damit experimentiert habe ich selbst allerdings noch nicht.

Gruß,

/dev

----------

## nic0000

 *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  :Wink: 

----------

## slick

 *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:

```
# 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

----------

## nic0000

 *slick wrote:*   

> 
> 
> Vorteile:
> 
> - Du brauchst keine weitere Software oder andere komplexe Einrichtung. 
> ...

 

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
> ...

 

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  :Wink: 

 *slick wrote:*   

> 
> 
> Klingt vielleicht alles im ersten Moment kompliziert, aber wenns einmal läuft merkt man kaum den Unterschied.

 

Das ist aber alles kompliziert  :Sad:  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   :Twisted Evil: 

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  :Wink: 

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...

----------

## Anarcho

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.

----------

## slick

 *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.

----------

## slick

 *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.

----------

## Anarcho

 *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.

----------

## nic0000

 *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  :Wink: 

----------

## Anarcho

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...  :Wink: 

----------

## slick

 *nic0000 wrote:*   

> Ich glaube du hast sein Problem nicht richtig verstanden.

 

Joar... jetzt wo Du das so sagst...  :Wink: 

 *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...  :Cool:  )

Habe übrigens das Gefühl ihr habt mein eines Post überlesen, oder wars auch sowas von daneben?  :Wink: 

----------

## nic0000

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.  :Wink: 

----------

## think4urs11

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.   :Twisted Evil: 

----------

## nic0000

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
> ...

 

Perfekt. Ich habe es gleich so ins Pflichtenheft übernommen  :Wink: 

 *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
> ...

 

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.  :Wink: 

Gute N8

----------

## think4urs11

 *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.   :Wink: 

----------

## nic0000

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  :Smile: 

 *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  :Wink: 

 *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.
> ...

 

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  :Twisted Evil: 

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?

----------

## Anarcho

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

----------

## nic0000

 *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.

----------

## think4urs11

 *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.
> ...

 

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   :Wink: 

 *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?

----------

## Anarcho

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.

----------

## think4urs11

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.)   :Wink: 

----------

## Anarcho

 *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.
> ...

 

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  :Wink: 

----------

## nic0000

Netter Plasch, ich bin auch noch da!!

 :Wink: 

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  :Wink: 

Wobei wir eigentlich schon wieder bei einer Reihe neuer Probleme sind  :Wink:  da ich der einzige Admin bin.

So, jetzt könnt ihr weglaufen  :Wink: 

----------

## think4urs11

 *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.   
> ...

 

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  :Wink: 

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?   :Rolling Eyes: 

 *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   :Twisted Evil: 

 *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.

----------

## Anarcho

 *Think4UrS11 wrote:*   

>  *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.   
> ...

 

Dem kann ich mich anschliessen!

 *Think4UrS11 wrote:*   

> 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'
> ...

 

Klar, wenn man ebenfalls vom gleichen VPN für die Admins ausgeht dann wäre das client-to-client (wie ich schon weiter oben schrieb).

Aber ich verstehe nicht ganz warum du jedem Client immer ein ganzes Subnetz geben möchtest. Vielleicht reden wir auch an einander vorbei, aber für mich ist jetzt ein Client genau 1 Rechner, nämlich den den ich administrieren möchte.

Für die Verbindung des Admin zum Server kann man natürlich mehrere Wege gehen, einmal den von dir beschriebenen 2. VPN Tunnel, den gleichen VPN Tunnel, also client-to-client oder man verbindet sich per SSH auf den Server und von aus weiter. Ich würde ebenfalls Variante 1 nehmen.

----------

## nic0000

 *Think4UrS11 wrote:*   

> Im Gegentum, bin beinahe schon begeistert! (ernstgemeint!)

 

Beinahe??

 *Think4UrS11 wrote:*   

> Zeit ist halt immer so eine Sache... Rechenzentren haben die dumme Angewohnheit auf Privatleben exakt gar keine Rücksicht zu nehmen.

 

Das hast du schön gesagt  :Wink: 

 *Think4UrS11 wrote:*   

> Hat die ne (hübsche, freie) Schwester mit Faible für EDVler?   

 

Nee, aber eine AS400 Programmiererin als Mutter  :Wink: 

Ja, die ist Solo.

 *Think4UrS11 wrote:*   

> 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  

 

Hej, ich bin mein Avatar  :Twisted Evil: 

 *Think4UrS11 wrote:*   

>  *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?

 

Ich glaube ja. Was auch nicht schlimm ist, denn in fast jedem Netz ist nur ein Client oder anders Ausgedrückt: Da es sich um Private Workstations handelt stehen in der Regel 1 und nie mehr als 3 von unseren Kisten herrum. Was im Netzwerk sonst so passiert interessiert mich nicht, so es unseren Zugriff nicht stört.

 *Think4UrS11 wrote:*   

> 
> 
> 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'
> ...

 

Ich habe wohl heute meinen Babelfish verloren, warum verstehe ich wieder so wenig  :Rolling Eyes:  ?

----------

## think4urs11

 *nic0000 wrote:*   

> Beinahe??

 Berufskrankheit. Admin; Berufszyniker; gestraft mit 'Usern'; Paranoiker aus Leidenschaft und schwer (positiv wie negativ) aus der Fassung zu bringen.

 *Think4UrS11 wrote:*   

> Nee, aber eine AS400 Programmiererin als Mutter ... Ja, die ist Solo.

 Alter, Bundesland, Telefonnummer, sonstige relevante Details?

 *nic0000 wrote:*   

>  *Think4UrS11 wrote:*   
> 
> 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'
> ...

 

Spiel ich mal den Erklärbär...

- du hast einen Admin und einen Klienten

- beide wollen getunnelt 'miteinander'

- beide bauen hierzu einen eigenen Tunnel zum Server auf

- dadurch entsteht übers Internet ein privates VPN-Netz in dem ausschließlich mit IP-Adressen 10.x.y.z gearbeitet wird

- 'Router' für diese Netze sind dann auf beiden Seiten jeweils die PCs die den Tunnel zum Server aufgemacht haben

- ein Admin der im Tunnel z.B. die IP 10.0.1.57 hat kann direkt (wie in einem LAN) auf einen PC bei Klient zugreifen der z.B. 10.0.37.188 hat, und zwar mit was auch immer (Netzlaufwerke, ssh, http, whatever) ohne zusätzlich erst noch einen port forward einzurichten. Genau das macht ja OpenVPN... besteht der Tunnel erstmal ist alles was da durchläuft für die Clients auf beiden Seiten vollkommen transparent.

(kleiner) Schönheitsfehler dabei fällt mir gerade auf... dazu müßte natürlich wie oben geschrieben ein PC bei Klient - nämlich der der den OpenVPN Tunnel aufbaut - gleichzeitig auch als Router fungieren um die Daten von nicht tunnelnden PCs durch den Tunnel zu schieben.

Analog auf Adminseite aber da stellt sich das Problem weniger da ja Klient selten bei Admin im Netz herumpfuschen soll sondern nur umgekehrt gell.

Genaugenommen kannst du auch jedem Admin seine 'eigene' C-Klasse (ein /24) zuweisen, aus technischer Sicht des Server ist ein Admin ja auch nur ein Klient der was von ihm will. Vereinfacht die Sache (gehirntechnisch) wenn alle Beteiligten die gleiche Netzmaske haben.

... zum Glück sind wir hier im Diskussionsforum sonst würden uns amne/Earthwings/slick was erzählen so weit wie wir schon vom ursprünglichen Thema weg sind manchmal ...   :Rolling Eyes: 

----------

## Anarcho

Was beim routing bei getrennten Subnetzen noch ein Problem ist, ist das der Client nicht weiss wohin er Traffic vom Adminnetz kommend zurückschicken soll.

Dann müsste man extra einen route eintrag erstellen der z.b. sagt: Traffic für netz 10.0.1.0/24 wird über 10.0.4.1 geleitet (der Client hat dann 10.0.4.x/24)

Oder man fasst die Netzmaske etwas weiter auf dem Client: 10.0.0.0/16 (entweder in der route oder komplett) und auf dem server dann ne /24 Netzmaske denn der Server kennt ja alle Routen der einzelnen VPNs.

Oder halt alle Teilnehmer in ein Subnetz.

Dann könnte es aber bei vielen Clients bald eng werden und bei getrennten kann man schön aufteilen (10.1.1.0/24 ist Hamburg, 10.1.2.0/24 ist Frankfurt, usw.)

Bei steigender Anzahl muss man halt die Netzmaske erhöhen (10.1.0.0/16 NRW, 10.2.0.0/16 Bayern, ...)

----------

## nic0000

 *Anarcho wrote:*   

> Oder halt alle Teilnehmer in ein Subnetz.
> 
> Dann könnte es aber bei vielen Clients bald eng werden und bei getrennten kann man schön aufteilen (10.1.1.0/24 ist Hamburg, 10.1.2.0/24 ist Frankfurt, usw.)
> 
> Bei steigender Anzahl muss man halt die Netzmaske erhöhen (10.1.0.0/16 NRW, 10.2.0.0/16 Bayern, ...)

 

Langsam mit den Jungen Pferden, das Projekt ist z.Z. auf Hamburg beschränkt, denn es geht hierbei nicht darum Rechner zu Administrieren sondern eine gute lokale Versorgung mit Schulungen und Support zu gewährleisten. Ihr kennt doch die Probleme mit Linux und Normalsterblichen, daher erspare ich mir darauf näher einzugehen.

Der Wachstum wird durch die Schulungskapatzität beschränkt.

----------

## nic0000

 *Think4UrS11 wrote:*   

> Berufskrankheit. Admin; Berufszyniker; gestraft mit 'Usern'; Paranoiker aus Leidenschaft und schwer (positiv wie negativ) aus der Fassung zu bringen.

 

Naja, dann hast du es noch gut. Ich bin oben drein defensiver Pessimist...

 *Think4UrS11 wrote:*   

> Alter, Bundesland, Telefonnummer, sonstige relevante Details?

 

45 Jahre, 172 cm, indisch/karaibisch mix, trinkt und raucht nicht. Spricht nativ Französisch und mit einen charmanten Akzent Deutsch.

Jetzt kommts:

Ansonsten hat sie "nur" die Berufskrankheiten eines Programmieres  :Twisted Evil: 

Ihr Charakter ist "zart und einfühlsam" wie von einer Person in ihrer Position und 20 Jahren Arbeit in diesem doch so "frauenfreundlichen" Beruf erwartet.  :Twisted Evil:   :Twisted Evil: 

Noch nie hat jemand (schon garnicht eine Frau) so kreative "Nicknames" für mich erfunden wie sie, und jedes mal wenn wir uns sehen bin gespannt was mir meine Frau anschließend so köstliches aus dem Französischen übersetzen wird.   :Twisted Evil:   :Twisted Evil:   :Twisted Evil: 

Interessiert?

 *Think4UrS11 wrote:*   

> Spiel ich mal den Erklärbär...

 

Kann der Erklärbär auch die "1-5 müßte sich (theoretisch) vom Klienten mit einer einzigen ssh Befehlszeile machen lassen" in Form einer Step-byStep Anleitung erklären  :Very Happy:  ?

 *Think4UrS11 wrote:*   

> ( kleiner) Schönheitsfehler dabei fällt mir gerade auf... dazu müßte natürlich wie oben geschrieben ein PC bei Klient - nämlich der der den OpenVPN Tunnel aufbaut - gleichzeitig auch als Router fungieren um die Daten von nicht tunnelnden PCs durch den Tunnel zu schieben.

 

Also in meinem Scenario gibt es diese anderen PCs nicht.

 *Think4UrS11 wrote:*   

> ... zum Glück sind wir hier im Diskussionsforum sonst würden uns amne/Earthwings/slick was erzählen so weit wie wir schon vom ursprünglichen Thema weg sind manchmal ...  

 

Manchmal denke selbst ich mit  :Wink: 

----------

## think4urs11

 *nic0000 wrote:*   

> 45 Jahre, 172 cm, indisch/karaibisch mix, trinkt und raucht nicht. Spricht nativ Französisch und mit einen charmanten Akzent Deutsch.
> 
> ....

 mh, knapp außerhalb meines Wunschaltersfensters (25 < X < 40) aber sonst feinifeini

 *nic0000 wrote:*   

> Kann der Erklärbär auch die "1-5 müßte sich (theoretisch) vom Klienten mit einer einzigen ssh Befehlszeile machen lassen" in Form einer Step-byStep Anleitung erklären?

 

Auf PC Klient:

```
ssh <username Klient auf Server>@<ip server> screen -dmLS Klient ssh remotesupport@<ip PC Klient>
```

Vom PC Klient wird eine SSH-Sitzung zum Server aufgebaut innerhalb derer eine Screensession (mit Name Klient) gestartet -und sofort detached- wird innerhalb derer eine SSH-Session zum PC Klient gestartet wird für den user remotesupport.

Ergebnis:

- An PC Klient erscheint der Prompt direkt nach ausführen obigen Befehls wieder als wäre nichts gewesen

- Am Server läuft ab diesem Zeitpunkt eine neue Screensession die einen ssh zu Klient offen hat

Ein Admin kann nun hergehen und sich mittels screen -rd <Name des Klienten> auf dessen Maschine einklinken. Durch den '-L' ist das Logging für die Screensession gleich mitaktiviert.

Das ist jetzt zwar ohne spezielles port forwarding - das klappt irgendwie nicht so wie ich mir das dachte, macht aber nichts. Auf dem Server sind die einzelnen Screensessions trotzdem eindeutig da ja anhand des Klientennamens (-S Klient) unterscheidbar.

Wie bereits erwähnt, auf Server muß jeweils ein public key für den jeweiligen Klienten ohne Passphrase benutzt werden. Wahlweise zusätzlich auch einen solchen auf PC Klient dann geht es volltransparent und ist (imho) dau-tauglich.

damit das ganze auch zuverlässig länger läuft sollte auf beiden Seiten in der SSH config jeweils ein passender keepalive mit aktiviert sein damit die diversen Billig-NAT-Router nicht zwischendrin die Verbindung kappen wg. Nichtaktivität.

... das Pessimist sein seh ich nicht als nachteilig an bei mir. Auf die Art kann ich nur positiv überrascht werden - eindeutiger Vorteil  :Wink: 

----------

## nic0000

 *Think4UrS11 wrote:*   

>  *nic0000 wrote:*   45 Jahre, 172 cm, indisch/karaibisch mix, trinkt und raucht nicht. Spricht nativ Französisch und mit einen charmanten Akzent Deutsch.
> 
> .... mh, knapp außerhalb meines Wunschaltersfensters (25 < X < 40) aber sonst feinifeini

 

Schade, aber ich Bete wieder Täglich den Obercheff an, damit bloß meiner Frau nicht so einen Charakter durchbricht. Sie sind ja verwandt...  :Sad: 

 *Think4UrS11 wrote:*   

> Auf PC Klient:
> 
> ```
> ssh <username Klient auf Server>@<ip server> screen -dmLS Klient ssh remotesupport@<ip PC Klient>
> ```
> ...

 

Du warst mir ja am Anfang sympatisch...

Wo sind denn die 1000 Zeilen Code mit den ich jetzt gerechnet habe?

 *Think4UrS11 wrote:*   

> Das ist jetzt zwar ohne spezielles port forwarding - das klappt irgendwie nicht so wie ich mir das dachte, macht aber nichts. Auf dem Server sind die einzelnen Screensessions trotzdem eindeutig da ja anhand des Klientennamens (-S Klient) unterscheidbar.

 

Langsam fange ich dich wieder zu mögen...

 *Think4UrS11 wrote:*   

> Wie bereits erwähnt, auf Server muß jeweils ein public key für den jeweiligen Klienten ohne Passphrase benutzt werden. Wahlweise zusätzlich auch einen solchen auf PC Klient dann geht es volltransparent und ist (imho) dau-tauglich.

 

Verstehe nicht ganz? Auf dem Klient wozu? Um den Tunnel zum Server aufzubauen? Da weiß ich nicht so recht ob openVPn nicht besser geeignet währe.

 *Think4UrS11 wrote:*   

> damit das ganze auch zuverlässig länger läuft sollte auf beiden Seiten in der SSH config jeweils ein passender keepalive mit aktiviert sein damit die diversen Billig-NAT-Router nicht zwischendrin die Verbindung kappen wg. Nichtaktivität.

 

Entweder das, oder z.B. einen Cronjob der die Verbindung regelmässig anstößt z.B. 30 Min. Wenn die Verbindung aufgebaut ist kann sie wiederum vom Server aus bei bedarf gehalten werden. Ich habe das mal mit einen simplen Ping auf den Klient gemacht.

 *Think4UrS11 wrote:*   

> ... das Pessimist sein seh ich nicht als nachteilig an bei mir. Auf die Art kann ich nur positiv überrascht werden - eindeutiger Vorteil 

 

Aber das Glas ist dann trotzdem immer nur halb voll  :Sad: 

----------

## think4urs11

 *nic0000 wrote:*   

>  *Think4UrS11 wrote:*   Wie bereits erwähnt, auf Server muß jeweils ein public key für den jeweiligen Klienten ohne Passphrase benutzt werden. Wahlweise zusätzlich auch einen solchen auf PC Klient dann geht es volltransparent und ist (imho) dau-tauglich. 
> 
> Verstehe nicht ganz? Auf dem Klient wozu? Um den Tunnel zum Server aufzubauen? Da weiß ich nicht so recht ob openVPn nicht besser geeignet währe.

 

Dein Klient baut eine Verbindung zum 'Masterserver' auf wenn ihm geholfen werden soll. Ansonsten besteht diese Verbindung nicht, wozu auch? Nach Ende der Hilfsaktion wird der Tunnel beendet - und zwar vom Admin auf der Serverseite.

Alleine dein Klient entscheidet zu welchen Zeitpunkten eine Verbindung *in* sein Netz erlaubt ist und wann nicht. Ein dauerhaft offener Tunnel ist *immer* ein Sicherheitsrisiko.

Natürlich kannst du auf Klient-Seite (Account Klient auf Server genaugesagt) auch mit Passwort arbeiten. Nur muß sich dein Klient dieses Passwort dann auch merken  :Wink: 

 *nic0000 wrote:*   

>  *Think4UrS11 wrote:*   damit das ganze auch zuverlässig länger läuft sollte auf beiden Seiten in der SSH config jeweils ein passender keepalive mit aktiviert sein damit die diversen Billig-NAT-Router nicht zwischendrin die Verbindung kappen wg. Nichtaktivität. 
> 
> Entweder das, oder z.B. einen Cronjob der die Verbindung regelmässig anstößt z.B. 30 Min. Wenn die Verbindung aufgebaut ist kann sie wiederum vom Server aus bei bedarf gehalten werden. Ich habe das mal mit einen simplen Ping auf den Klient gemacht.

 

Pfui - genau für den Zweck gibt es ja diese ssh Option. Außerdem gibt es NAT-Implementierungen die jede einzelne Verbindung (d.h. jedes sourceip:sourceport <-> destip:destport Päärchen) seperat betrachten. Da bringt dir ein ping 'nebenher' dann gar nichts weil der als eigene Verbindung behandelt wird.

 *nic0000 wrote:*   

>  *Think4UrS11 wrote:*   ... das Pessimist sein seh ich nicht als nachteilig an bei mir. Auf die Art kann ich nur positiv überrascht werden - eindeutiger Vorteil  
> 
> Aber das Glas ist dann trotzdem immer nur halb voll

 

Quark, das nennt man doch dann Espresso. halbvoll ...du kennst ja häßliche Wörter ...

----------

## nic0000

 *Think4UrS11 wrote:*   

> Dein Klient baut eine Verbindung zum 'Masterserver' auf wenn ihm geholfen werden soll. Ansonsten besteht diese Verbindung nicht, wozu auch? Nach Ende der Hilfsaktion wird der Tunnel beendet - und zwar vom Admin auf der Serverseite.

 

Hilfsaktion ist jetzt eigentlich eher selten, planmässige Wartung. Ansonsten gefällt mir das so wie du das beschreibst. Ich denke mir aber das wir mehre Dienste darüber laufen lassen können, z.B. rsync und ftp download von distfiles vom unseren Server etc. Ich erwärme mich immer mehr für eine VPN Lösung...

 *Think4UrS11 wrote:*   

> Alleine dein Klient entscheidet zu welchen Zeitpunkten eine Verbindung *in* sein Netz erlaubt ist und wann nicht. Ein dauerhaft offener Tunnel ist *immer* ein Sicherheitsrisiko.

 

Der Klient entscheidet eigentlich gar nichts, denn die Fernwartung wird von außen initziert. Du gehst anscheinend von einen Linux-User aus, stell dir dann lieber so eine 70Jährige Oma vor die mit der Maus versucht den Browser zu öffnen. Allein schon die Vorstellung das Browserfenster in der Größe zu verstellen bringt sie schon in Atemnot  :Wink: 

Nein nein, die Leute werden durch das Schulungsprogramm Computerfit gemacht, auf den Maschinen ist eine bestimmte Menge an Software installiert, welche um die Reizflut gering zu halten, doch ziemlich karg ist. Die Maschinen werden auf den aktuellen Stand gebracht, gewartet und eventuell für die nächste Schulung mit neuer Software bestückt und das System garantiert das der Dozent alles so vorfindet wie er das braucht und nicht erstmal angst haben muss das die Kiste vom Enkel für eine Lanparty mit den neusten Spielen/Treiber/Würmern ausgestattet wurde. 

In Zukunft soll natürlich auch mehr möglich sein, das übersteigt aber zZ aber meine Kapazitäten. Die Benutzer haben kein administrativen Zugang zum System, die Kisten starten via Bioseistellung 1x in der Woche und werden bearbeitet  :Wink: 

Hoffe du verstehst jetzt besser die Anforderung, die ist wirklich nicht so hoch. Ich kann es teilweise selbst nicht glauben, aber einige betreue ich schon Jahrelang und es kamen einfach keine Beschwerden, im gegenteil sie sind nur froh wenn der Nachbar wieder von HorrorWürmern spricht die den Computer mitsamt den wichtigen Daten auffressen. 

 *Think4UrS11 wrote:*   

> Natürlich kannst du auf Klient-Seite (Account Klient auf Server genaugesagt) auch mit Passwort arbeiten. Nur muß sich dein Klient dieses Passwort dann auch merken 

 

Der "Klient" merkt sich genau ein Passwort: Sein Login

 *Think4UrS11 wrote:*   

> Pfui - genau für den Zweck gibt es ja diese ssh Option. Außerdem gibt es NAT-Implementierungen die jede einzelne Verbindung (d.h. jedes sourceip:sourceport <-> destip:destport Päärchen) seperat betrachten. Da bringt dir ein ping 'nebenher' dann gar nichts weil der als eigene Verbindung behandelt wird.

 

Da habe ich mich wohl unverständlich ausgedrückt. Gemeint war ein Ping innerhalb eines VPN Tunnels.  :Wink: 

 *Think4UrS11 wrote:*   

> Quark, das nennt man doch dann Espresso. halbvoll ...du kennst ja häßliche Wörter ...

 

Ich vergaß, apropos häßliche Worter, da habe ich noch gar nicht losgelgt  :Wink: 

----------

## think4urs11

Hmm achso na dann

Ursprünglich hatte ich die Anforderungen wirklich etwas anders ausgelegt. Tut der SSH-Lösung aber trotz allem keinen Abbruch, taugt genauso.

- das nach-Hause-telefonieren geschieht eben mit obiger Lösung

- verwendet wird hier ssh mit public keys ohne passphrase

- rsync/download läßt sich ebenfalls automatisiert darüber abwickeln

Wenn die Maschinen booten wird via /etc/init.d/local.start schonmal der 'Admin-Eingang' mitgestartet, braucht ja praktisch keine Ressourcen und Bandbreite auch faktisch null bis auf ein wenig keepalive (wie jeder aktive VPN-Tunnel).

Der Server kann ja problemlos nebenher als z.B. Portagemirror, http-replicator oder meinetwegen Schulungs-Video-Streamingserver nebenher mit genutzt werden - alles liefe (wenn notwendig) durch den SSH-Tunnel und zwar ohne das Klient das bewußt wäre (er sich darum kümmern muß) sobald es eingerichtet ist - da gibt sich das nicht sehr viel mit OpenVPN.

Um es nun ganz fein zu machen kann man auf dem Server die bestehenden Admin-Tunnel nach einer gewissen Zeit auch wieder automatisiert abbauen, z.B. weil an dem Tag der Admin keine Zeit hat.

Für den Fall der Fälle gibt es natürlich auf der Oberfläche der Klienten einen Button 'da werden sie geholfen' um den Admintunnel auch explizit manuell zu aktivieren.

Was ich damit sagen will ist das SSH durchaus für deine Anforderungen ausreicht.

Vorteil: Du brauchst keine VPN-Software die ja auch erstmal konfiguriert werden muß und die im Endeffekt ja *nur* für deine Zwecke auf der Maschine der Klienten herumliegt.

(Oma Krausse dürfte selten das Bedürfnis verspüren im 'Hamachi-Hausfrauen-VPN' Kochrezepte mit Tante Wang-To aus Peking an der staatlichen Kontrolle Chinas vorbei Kochrezepte zu tauschen   :Twisted Evil:   )

Software die nicht installiert ist muß auch nicht gewartet und upgedated werden, kann auch keine zusätzlichen Löcher aufreissen, etc.

SSH hingegen ist sowieso auf jeder gescheiten Linuxkiste mit installiert und aktiv. (Und ggf. auch für Kleinweich Fenster erhältlich)

Der initiale Aufwand das alles ans Laufen zu bekommen ist sicher etwas höher als mit OpenVPN das ist unbestritten. Ob und wie sich das langfristig verhält ist eine andere Geschichte.

Aber wie du siehst bist du prinzipiell frei in der Wahl der Waffen, gehen tut beides.

Nun mußt du dich entscheiden lieber Nico.

Wählst du die schicke junge Lady OpenVPN mit den großen Ohren die alles mit sich machen läßt und erfrischend unkompliziert ist?

Oder wählst du die ihrer Jugend bereits entwachsene Miss OpenSSH die frauentypisch etwas zickiger, andererseits jedoch sehr genügsam und ein verläßlicher Partner in allen Lebenslagen ist?

Entscheide dich, der Herzblatthubschrauber wartet bereits auf euch   :Wink: 

----------

## nic0000

 *Think4UrS11 wrote:*   

> Was ich damit sagen will ist das SSH durchaus für deine Anforderungen ausreicht.

 

Das habe ich mir schon immer heimlich gedacht, denn SSH ist schon ein feinifeini Werkzeug und eins der Gründe warum ich Linux/Unix liebe bzw. M$ hasse.   :Twisted Evil: 

 *Think4UrS11 wrote:*   

> Vorteil: Du brauchst keine VPN-Software die ja auch erstmal konfiguriert werden muß und die im Endeffekt ja *nur* für deine Zwecke auf der Maschine der Klienten herumliegt.

 

Ja die Lösung währe schon schlanker  :Wink: 

 *Think4UrS11 wrote:*   

> (Oma Krausse dürfte selten das Bedürfnis verspüren im 'Hamachi-Hausfrauen-VPN' Kochrezepte mit Tante Wang-To aus Peking an der staatlichen Kontrolle Chinas vorbei Kochrezepte zu tauschen    )

 

ehehe, du würdest staunen wie weit einige von ihnen heute sind. Da habe ich z.B. einen 65 Jährigen der kennt sich mit p2p und brennen besser aus als so manches Kiddy  :Wink: 

Dem habe ich schon seinen Laptop und die Kiste zu Hause zusammengeschaltet, damit er im Urlaub nach dem rechten sehen kann. Zu geil  :Wink: 

Das ist zwar eine Insellösung, allerdings spricht ja nichts später auch diesen Weg zu gehen, wobei sich

A)

alles bestimmt auch mit SSH einrichten lässt

B)

zu not auch ein vpn nachträglich auf die Kiste kommt.

C)

Die neuen SSH auch mit VPN-features kommt und bis dahin ist es auch erprobt. 

Du kennst nicht zufällig einen SSH-Gott der mir dabei unter die Arme greift?

 *Think4UrS11 wrote:*   

> Software die nicht installiert ist muß auch nicht gewartet und upgedated werden, kann auch keine zusätzlichen Löcher aufreissen, etc.

 

Das stimmt, allerdings gehe ich davon aus das selbst die sicherste Waffe in Kinderhänden eine Gefahr darstellt.   :Embarassed:   habe ich mich jetzt geoutet?

 *Think4UrS11 wrote:*   

> Nun mußt du dich entscheiden lieber Nico.
> 
> Wählst du die schicke junge Lady OpenVPN mit den großen Ohren die alles mit sich machen läßt und erfrischend unkompliziert ist?
> 
> Oder wählst du die ihrer Jugend bereits entwachsene Miss OpenSSH die frauentypisch etwas zickiger, andererseits jedoch sehr genügsam und ein verläßlicher Partner in allen Lebenslagen ist?
> ...

 

Oh die sind beide so charmant... Kann ich nicht beide haben?

Na gut, ich bin für das robuste Modell SSH. (Irgendwie lande ich wohl doch immer bei den selben Frauen) 

Ich wollte mich sowieso näher mit SSH beschäftigen, da ich aber tendenziell faul bin (währe ich wohl sonst in der IT?), ist es gut das ich "zart" genötigt werde mich darum auch mal zu kümmern.  :Wink: 

Hey, bist du noch da? Was macht eigentlich dein ICQ?

----------

