Johannes Franken
<jfranken@jfranken.de>

Inhalt

1. X11-forwarding
2. Pipes
   1. imap (fetchmail, mutt)
   2. smtp (exim)
   3. rsync
   4. scp, sftp
   5. uucp
   6. cvs
3. Port forwarding
   1. Local port forwarding
   2. Remote port forwarding
   3. Tunnels ineinander stecken
4. ppp over ssh
5. Umgang mit Netz-Timeouts
   1. Keepalives
   2. autossh
6. Weiterführendes

X11-forwarding

• ohne X11-Tunnel:

  

  
  

  jfranken@hamster: $ xhost gate gate being added to access control list jfranken@hamster: $ ssh gate jfranken@gate: $ export DISPLAY=hamster:0 jfranken@gate: $ netscape & [1] 17101 jfranken@gate: $

  
  
• mit X11-Tunnel:

  

  
  

  jfranken@hamster: $ export DISPLAY=:0 jfranken@hamster: $ ssh -X gate jfranken@gate: $ echo $DISPLAY localhost:10.0 jfranken@gate: $ netscape & [1] 17153 jfranken@gate: $

  
  

  Hierzu muß auf gate die libX.so und xauth installiert sein und X11Forwarding yes in /etc/ssh/sshd_config stehen.

  Alternativ zu dem -X-Parameter kann man dem ssh den Parameter -o ForwardX11=yes übergeben oder in der ~/.ssh/config-Datei ForwardX11 yes eintragen.

Bewertung:

Pipes

• Die folgende Befehlsfolge zeigt den Füllstand der Rootpartition des Rechners gate an:
  

  $ ssh gate df | awk '/\/$/ {print $5}' 64% $

  
  
• Die folgende Befehlsfolge kopiert das Verzeichnis mydir in das /tmp-Verzeichnis des Rechners gate
  

  $ tar cf - mydir/ | ssh gate 'cd /tmp && tar xpvf -'

  
  

imap (fetchmail, mutt)

jfranken@hamster $ ssh gate imapd
* PREAUTH [231.36.30.64] IMAP4rev1 v12.264 server ready

• fetchmail: Alle Mail an die Domain jfranken.de landet bei meinem Provider (our-isp.org), von wo fetchmail sie regelmäßig über imap auf meinen lokalen Mailserver (gate.jfranken.de) abholt. Mit der folgenden ~/.fetchmailrc tunnelt fetchmail die imap-Kommunikation über ssh:
  

  poll johannes.our-isp.org with options proto imap, preauth ssh, plugin "ssh -x -C jfranken@%h /usr/local/bin/imapd Maildir 2>/dev/null", smtphost gate, fetchall

  
  
• mutt: Meine Mail liegt also auf gate, und ich greife normalerweise lokal mit mutt über imap darauf zu. Falls ich dies von einem anderen Rechner versuche (z.B. mit dem Notebook über's Internet), tunnelt mutt die imap-Kommunikation zu gate über ssh. Folgende Zeilen in der ~/.muttrc ermöglichen das:
  

  set tunnel="imapd || ssh -qC jfranken@gate.jfranken.de imapd" set folder="{gate}~/Mail"

  
  

smtp (exim)

ssh:
  driver = pipe

  bsmtp = all
  bsmtp_helo = true
  use_crlf = true
  prefix = ""
  suffix = ""

  command = ssh johannes.our-isp.org netcat -w 1 localhost smtp
  user = jfranken

  timeout = 300s
  temp_errors = 1
  return_fail_output = true

t_online:
  driver = domainlist
  transport = ssh
  route_list = "^t-online\.(de|at|com)|t-dialin\.net$ ;^mail.com$                            ;^lists.sourceforge.net$               ;^bigpond.com$                         ;^aol.com$                             ;^mathematik.tu-darmstadt.de$          ;"

rsync

$ rsync --delete -a -e ssh ./ jfranken@www.jfranken.de:public_html/

scp, sftp

uucp

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,
command="/usr/sbin/uucico -l" ssh-rsa AAAAB3NzaC1yc2 ...

/etc/uucp/sys:
        system YOURPROVIDER
        call-login *
        call-password *
        time any
        chat " \d\d\r\c ogin: \d\L word: \P"
        chat-timeout 30
        protocol i
        port ssh

/etc/uucp/port:
        port ssh
        type pipe
        command /usr/bin/ssh -qi ~/.ssh/id_rsa.uucp uucp@YOURPROVIDER
        reliable true
        protocol etyig

cvs

no-port-forwarding,no-X11-forwarding,command="/usr/bin/cvs server" ssh-rsa AAAAB3NzaC1yc2...

$ export CVS_RSH=ssh
$ export CVSROOT=:ext:cvs@host:/export/home/cvs

$ cvs co module

Port forwarding

Local port forwarding

Im Browser würde http://hamster:4321 also genauso aussehen wie die Webseite von IBM.

Man muss auf hamster Rootrechte haben, wenn man einen lokalen Port <1024 öffnen möchte.

Wenn man den -g Parameter weglässt, können Clients den Port nur über die IP-Adresse 127.0.0.1 oder entsprechende Aliase (z.B. localhost) erreichen, müssen also auf dem selben Rechner wie der ssh-Client laufen, oder aus einem anderen Tunnel dort umsteigen.

Sollen die Benutzer auf dem sshd-Rechner keinen Shellzugriff, sondern nur Portforwarding können, kann man zunächst in der /etc/ssh/sshd_config die Option PasswordAuthentication=no setzen und dann für jeden betreffenden Publickey in der ~/.ssh/authorized_keys am Zeilenanfang einen Aufruf wie command="/bin/cat" oder command="sleep 2000d" einfügen.

Wer zusätzlich einen keepalive einbauen möchte, damit die Natting-Tabelle der Firewall im Leerlauf die Tunnels nicht kappt, schreibt an den Beginn der Publickeyzeilen jeweils:
command="while :;do date;sleep 10;done"

Um die möglichen Portforwoarding-Ziele zu beschränken, kann man eine Liste von permitopen-Optionen vor den jeweiligen Publickeys einfügen, z.B.:
permitopen="192.168.42.5:80",permitopen="127.0.0.1:8080"

Remote port forwarding

Wer im Browser http://gate:9030 aufruft, landet auf dem Intranetserver.

Man muss auf gate Rootrechte haben, wenn man remote Port <1024 öffnen möchte. Wer den Rootzugriff per ssh nicht erlauben möchte, kann den ssh-Tunnel auf einen hohen Port (z.B. 9030) legen und mit xinetd, netcat oder Firewallregeln auf Port 80 umleiten.

Dies leisten folgende /etc/inetd.conf:

80  stream tcp nowait nobody /bin/nc /bin/nc -w 3 localhost 9030

service intranet
{
        type            = UNLISTED
        flags           = REUSE
        socket_type     = stream
        protocol        = tcp
        user            = root
        wait            = no
        instances       = UNLIMITED
        port            = 80
        redirect        = localhost 9030
        disable         = no
}

echo 1 > /proc/sys/net/ipv4/ip_forward # turns on forwarding
iptables -F -t nat # Flush existing translation tables
iptables -t nat -A PREROUTING -p tcp --dport 9030 -j DNAT --to localhost:80
iptables -t nat -A POSTROUTING -j MASQUERADE

Der sshd bindet die remote Tunnels in seiner Standardkonfiguration an das loopback-Interface; er nimmt also nur Verbindungen von localhost entgegen. Wer möchte, dass seine Tunnels auf allen Netzinterfaces erreichbar sind, trage in der /etc/ssh/sshd_config auf gate die Zeile GatewayPorts yes ein oder leite den Port wie oben beschrieben mit ssh oder xinetd um.

Tunnels ineinander stecken

Mit jedem weiteren Tunnel erhöhe ich die Reichweite um bis zu zwei Hosts:

ppp over ssh

Konfiguration des Servers:

1. Installation ppp (z.B. Version 2.4.1.uus-4 aus Debian GNU/Linux 3.0)
2. Dateirechte prüfen:
   

   $ ls -l /usr/sbin/pppd -rwsr-xr-- 1 root dip 230604 10. Dez 2001 /usr/sbin/pppd*

   
   
3. Einen Benutzer anlegen, der zum Aufruf des pppd berechtigt ist:
   

   $ adduser --group dip pppuser

   
   
4. PAP-Passwort und IP-Adressbereich vergeben:
   

   $ echo 'pppuser * geheim *' >> /etc/ppp/pap-secrets

   
   
5. In der ~pppuser/.ssh/authorized_keys den RSA-keys IP-Adressen zuordnen (Eine Zeile pro Publickey):
   

   no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/sbin/pppd remotename pppuser refuse-chap refuse-mschap refuse-mschap-v2 refuse-eap require-pap 192.168.45.1:192.168.45.2 notty debug linkname pppoverssh" ssh-rsa AAAAB3NzaC1...

   
   
6. Die /etc/ppp/ip-up.d/*-Scripts von allen störenden Routing- und Firewall-Initialisierungen bereinigen, welche die Distribution für die Interneteinwahl vorgesehen hatte. Wenn auf dem Rechner weitere PPP-Verbindungen (z.B. DSL-Einwahl ins Internet) erforderlich sind, können sich die Scripts an der $LINKNAME-Variablen orientieren, die den Wert "pppoverssh" hat.

Konfiguration des Clients:

1. Installation ppp (z.B. Version 2.4.1.uus-4 aus Debian GNU/Linux 3.0)
2. Sicherstellen, dass der User den pppd setsuid aufrufen kann:
   

   $ ls -l /usr/sbin/pppd -rwsr-xr-- 1 root dip 230604 10. Dez 2001 /usr/sbin/pppd* $ usermod -G dip jfranken

   
   
3. Einen neuen Provider anlegen:
   

   $ cat >/etc/ppp/peers/ssh <<EOF pty 'ssh -e none pppuser@SERVER-HOSTNAME false' user pppuser nodetach linkname pppoverssh # debug EOF

   
   
4. Das PAP-Passwort des Serves eintragen:
   

   $ echo 'pppuser * geheim' >> /etc/ppp/pap-secrets

   
   
5. /etc/ip-up.d/* ggf. anpassen (z.B. defaultroute auf $PPP_IFACE umsetzen)

jfranken@hamster:~ $ /usr/sbin/pppd call ssh
Using interface ppp0
Connect: ppp0 <--> /dev/ttyp4
Remote message: Login ok
kernel does not support PPP filtering
Deflate (15) compression enabled
Cannot determine ethernet address for proxy ARP
local  IP address 192.168.45.2
remote IP address 192.168.45.1

Umgang mit Netz-Timeouts

Keepalives

• Da es keinen ServerAliveInterval-Parameter für den Client gibt, bleibt der Client bei einigen Netzproblemen (z.B. NAT-Timeouts) mindestens eine Viertelstunde hängen, was für die getunnelten Verbindungen besonders lästig ist.
• Wenn man ProtocolKeepAlives=0, KeepAlive=no und ClientAliveInterval=0 setzt und nach der Authentifizierung nichts mehr sendet, kann man die Netzverbindung trennen und beliebig (z.B. Jahre) später fortsetzen.

autossh

1. den ssh-Client startet ,
2. sich dabei mit zwei Portforwardings eine Testschleife einrichtet ,
3. regelmäßig die Verbindung über die Testschleife prüft und
4. den ssh-Client bei Problemen stoppt und erneut aufruft .

$ export AUTOSSH_GATETIME=30
$ export AUTOSSH_POLL=15
$ autossh -M 20000 -g -N -C -L 143:localhost:143 gate.jfranken.de

$ alias ssh=':& a=$! ; port=$(( $a%45536 +20000 ))
  AUTOSSH_GATETIME=30 AUTOSSH_POLL=15 autossh -M $port'
$ ssh -g -N -C -L 143:localhost:143 gate.jfranken.de
[1] 6418

Weiterführendes

• Teil 3: Firewalls durchboren
• The Secure Shell TM Frequently Asked Questions
• OpenSSH Projekt Seite

---

$Id: ssh2.wml,v 1.42 2006/01/08 18:52:11 jfranken Exp $ [ChangeLog] $Id: template.inc,v 1.82 2010-09-04 12:58:17 jfranken Exp $ [ChangeLog] © Johannes Franken. Impressum und Haftungsausschluß