ssh-agent mit Git unter Windows

PS> [Environment]::SetEnvironmentVariable("GIT_SSH", "$((Get-Command ssh).Source)", [System.EnvironmentVariableTarget]::User)

Um unter Windows den ssh-agent zusammen mit Git nutzen zu können, sind ein paar Schritte notwendig:

  1. SSH-Agent aktivieren
    Dazu einfach in der Powershell den Service aktiveren und prüfen ob die Pfade richtig konfiguriert ist:
PS> Get-Service ssh-agent | Set-Service -StartupType Automatic
PS> Get-Command ssh | Select-Object Source

Source
------
C:\Windows\System32\OpenSSH\ssh.exe

2. SSH-Agent starten

PS> ssh-agent

3. Keys importieren

Entweder direkt mit

ssh-add

Oder indirekt über ein Passwort-Tool. Ich nehme dazu keepassxc.

4. GIT_SSH setzen
Abschließend muss nur noch die Umgebungsvariable GIT_SSH richtig gesetzt werden:

PS> [Environment]::SetEnvironmentVariable("GIT_SSH", "$((Get-Command ssh).Source)", [System.EnvironmentVariableTarget]::User)


Statische Routen mit dem NetworkManager

Ich hatte eben das Problem, dass ich statische Routen für eines meiner OpenVPN Tunnel anlegen wollte. Das Problem war jedoch, dass der NetworkManger keine „pseudo“ IPs via vpn_gateway oder ähnliches akzeptiert. Daher blieb mir nur der Weg über ein Skript. Beim Up und Down einer Netzwerkverbindung ruft der NetworkManager die Dispatcher Skripte unter /etc/NetworkManager/dispatcher.d/ auf. … „Statische Routen mit dem NetworkManager“ weiterlesen

Ich hatte eben das Problem, dass ich statische Routen für eines meiner OpenVPN Tunnel anlegen wollte. Das Problem war jedoch, dass der NetworkManger keine „pseudo“ IPs via vpn_gateway oder ähnliches akzeptiert. Daher blieb mir nur der Weg über ein Skript. Beim Up und Down einer Netzwerkverbindung ruft der NetworkManager die Dispatcher Skripte unter /etc/NetworkManager/dispatcher.d/ auf. Daher habe ich

  1. Der entsprechenden NetworkManager Verbindung ein fixes Interface zugeordnet (im Beispiel tun2) und
  2. Mir folgendes Skript /etc/NetworkManager/dispatcher.d/98-private-routes gebaut:

    [shell]
    #!/bin/sh

    if [ „$1“ == „tun2“ ]; then

    GW=`route -n | grep tun2 | grep „0.0.0.0“ | grep „255.255.255.255“ | cut -f1 -d“ „`
    echo $1“ „$2“ „$GW > /tmp/foo

    case „$2“ in
    up|vpn-up)
    ip r a 192.168.128.12/32 via $GW # VM
    ip r a 10.0.0.0/16 via $GW # 10er Netz
    ;;
    esac

    fi

    [/shell]
    Down ist nicht notwendig, da die Routen sowieso mit dem Interface wegfliegen

namebench – oder jede Sekunde zählt

Mal wieder ein wirklich gutes Tool, was man sich als road warrior merken sollte: namebench. Damit ermittelt man die optimalsten Nameserver für den jeweiligen Client. Das kann manchmal schon zu einem deutlich flüssigeres Gefühl beim Surfen führen. Hier das Ergebnis meines lokalen Clients. Obwohl Google gewonnen hat, bleibe ich bei meinen Einstellungen. Die wissen ja … „namebench – oder jede Sekunde zählt“ weiterlesen

Mal wieder ein wirklich gutes Tool, was man sich als road warrior merken sollte: namebench. Damit ermittelt man die optimalsten Nameserver für den jeweiligen Client. Das kann manchmal schon zu einem deutlich flüssigeres Gefühl beim Surfen führen.

Hier das Ergebnis meines lokalen Clients. Obwohl Google gewonnen hat, bleibe ich bei meinen Einstellungen. Die wissen ja sowieso schon alles ;-).

ssh ProxyCommand

ssh ProxyCommand ist verdammt praktisch, wenn man auf Server in einer DMZ nicht direkt drauf kommt, sondern einen Hob dazwischen nehmen muss. Ohne ssh ProxyCommand sieht der übliche Weg wie folgt aus: desktop$ ssh firewall firewall$ ssh dmzhost dmzhost$ Wie unpraktisch! Ein wenig besser ist desktop$ ssh -t firewall ssh dmzhost dmzhost$ Aber mit ssh … „ssh ProxyCommand“ weiterlesen

ssh ProxyCommand ist verdammt praktisch, wenn man auf Server in einer DMZ nicht direkt drauf kommt, sondern einen Hob dazwischen nehmen muss. Ohne ssh ProxyCommand sieht der übliche Weg wie folgt aus:

desktop$ ssh firewall
firewall$ ssh dmzhost
dmzhost$

Wie unpraktisch! Ein wenig besser ist

desktop$ ssh -t firewall ssh dmzhost
dmzhost$

Aber mit ssh ProxyCommand geht das ganze deutlich schicker. Dazu muss man folgendes in seiner .ssh/ssh_config oder in der /etc/ssh/ssh_config ergänzen:

Host dmzhost
  Hostname dmzhost
  User username
  ForwardAgent yes
  Port 22
  ProxyCommand ssh remoteuser@firewall nc %h %p

2 Dinge sind dabei erwähnenswert: 1. Durch netcat (nc) ist über den Weg auch scp möglich und 2. kann man diese ssh-Kette beliebig weiter führen. Kann man zum Beispiel einen internen Host nur über dmzhost erreichen so hilft folgender Eintrag weiter:

Host internalhost
  Hostname internalhost
  User username
  ForwardAgent yes
  Port 22
  ProxyCommand ssh remoteuser@dmzhost nc %h %p

Cool, oder? Natürlich müssen dmzhost, internalhost, firewall durch die richtigen auflösbaren Hostnamen ersetzt werden und der username muss natürlich auch dem richtigen entsprechen.

Aufgeschrieben habe ich mir das, weil ich heute darüber mit einem Kollegen gesprochen habe und leider nachsehen musste (RTFM).

Facebook spricht jetzt Jabber

Endlich kann man Facebook per Jabber Client direkt nutzten. Die fehlerträchtigen Clients/Plugins kann man jetzt getrost beiseite legen. Mehr dazu hier. Dort wird vorbildlich die Einrichtung der verschiedenen Clients gezeigt.

Endlich kann man Facebook per Jabber Client direkt nutzten. Die fehlerträchtigen Clients/Plugins kann man jetzt getrost beiseite legen. Mehr dazu hier. Dort wird vorbildlich die Einrichtung der verschiedenen Clients gezeigt.

Redundante Default Routen und Lastverteilung unter Linux

Anders als viele glauben kann ein Linux „Router“ nicht nur ein Default Gateway besitzen sondern mehrere. Das macht bei 2 Szenarien Sinn: Autofailover Definiert man 2 Default Routen etwa mit: route add default gw 172.16.1.1 dev eth1 route add default gw 172.16.2.1 dev eth2 So wird die zweite Default Route dann verwendet, wenn die erste … „Redundante Default Routen und Lastverteilung unter Linux“ weiterlesen

Anders als viele glauben kann ein Linux „Router“ nicht nur ein Default Gateway besitzen sondern mehrere. Das macht bei 2 Szenarien Sinn:

  1. Autofailover
    Definiert man 2 Default Routen etwa mit:

    route add default gw 172.16.1.1 dev eth1
    route add default gw 172.16.2.1 dev eth2
    

    So wird die zweite Default Route dann verwendet, wenn die erste einen Timeout liefert.

  2. Loadbalancing
    Das geht auch ganz einfach:

    ip route del default
    ip route add default equalize nexthop via 172.16.1.1 dev eth1 nexthop via 172.16.2.1 dev eth2 

    . Am besten trägt man das in /etc/rc.d/rc.local ein. Dann übersteht es auch einen Reboot.

Beiden Methoden ist übrigens gemein, dass der Timeout einer ausgefallenen Default Route noch angepasst werden muss. Der Default Timeout liegt bei stolzen 300 Sekunden.

cat /proc/sys/net/ipv4/route/gc_timeout
300

Das bedeutet, dass erst nach 5 Minuten die entsprechende Route deaktiviert wird. Umstellen kann man diesen Wert über sysctl. Also in /etc/sysctl.conf folgendes eintragen:

net.ipv4.route.gc_timeout = 10

und mit

sysctl -p

aktivieren

Google Public DNS

Google Public DNS den Link muss ich mir merken. Google hat doch tatsächlich wieder einen neuen Weg gefunden, wie sie mitbekommen wo Leute surfen. Ich bin skeptisch … Einen Vorteil hat das Teil jedoch: Mit der IP 8.8.8.8 kann man sich endlich mal eine IP merken, die man in Zukunft immer pingen kann 🙂

Google Public DNS den Link muss ich mir merken. Google hat doch tatsächlich wieder einen neuen Weg gefunden, wie sie mitbekommen wo Leute surfen. Ich bin skeptisch …

Einen Vorteil hat das Teil jedoch: Mit der IP 8.8.8.8 kann man sich endlich mal eine IP merken, die man in Zukunft immer pingen kann 🙂

ssh-copy-id

Eben habe ich in einem Wiki gelesen, wie man für SSH einen Public Key kopieren soll: cat ~/.ssh/id_rsa.pub | ssh root@172.16.1.1 ‚cat – >> ~/.ssh/authorized_keys‘ Bei dem Tipp sind mehrere Dinge problematisch: wer sagt, dass es ein rsa Key ist und kein dsa? gibt es .ssh schon? hat .ssh und authorized_keys die richtigen Rechte? Die … „ssh-copy-id“ weiterlesen

Eben habe ich in einem Wiki gelesen, wie man für SSH einen Public Key kopieren soll:

cat ~/.ssh/id_rsa.pub | ssh root@172.16.1.1 'cat - >> ~/.ssh/authorized_keys'

Bei dem Tipp sind mehrere Dinge problematisch:

  1. wer sagt, dass es ein rsa Key ist und kein dsa?
  2. gibt es .ssh schon?
  3. hat .ssh und authorized_keys die richtigen Rechte?

Die Befehlszeile müsste weit umfangreicher sein…

Aber halt es geht viel einfacher mit

ssh-copy-id user@host

Mehr Optionen unter man ssh-copy-id

PS: MAC OS X kennt das Kommando nicht …