I started this section with its subsection(s), because going through such an FTP gateway enforces special conventions. I had to face more than one such sort of FTP gateways during the last couple of years with different customers, and once again I started thinking, that after all that time it's worth having a single place where to collect that kind of information.
This is how you specify such a gateway with ???gFTP:
USER %hu@%pu@%hh PASS %hp@%pp
It is not necessarily always your (UNIXish) host my_DynDNS_host.dyndns.org
[16]
running an SSH daemon,
through which hosts like classicgate.t-online.de can be reached through an SSH tunnel.
But where else do we have an account with an SSH daemon supporting port forwarding out there?
Usually that's a UNIX shell account,
and I have one on WIN-shuttle.
ssh port forwardings always have to be carried out as root,
if the local port involved is a Well Known Port,
that is a port between 0 and 1023.
Otherwise I prefer to let it be done by a non-privileged user account.
You can (in theory) do a lot through proxies simply using TransConnect w/o involving ssh[17], but in reality you will soon love the advantages of ssh's extra capabilites like encryption and its pretty flexible port forwarding.
The proxy of one of my clients supported PROXY CONNECT only on port 443, i.e. HTTPS,
and because I preferredly use tconn together with ssh,
you will find ssh's -p 443 quite a few times further down,
which tells ssh to connect to somewhere outside on port 443,
and this is also through the proxy port 443.
RTFM tconn's documentation on how to adapt the configuration to your environment!
$ env LD_PRELOAD=$HOME/.tconn/tconn.so \
ssh \
-p 443 \
my_account@199.199.199.199
Port 866 on classicgate.t-online.de gives access to Btx via TCP/IP.
Obviously a Windows Btx decoder will try in vain to access that port,
if it's surrounded by a firewall,
so the idea is to forward that port from outside the firewall to inside the firewall
and let a capable host play the role of classicgate.t-online.de.
“Playing the role of ...” is done by a few different necessary factors:
the IP address of classicgate.t-online.de
needs setting to the local address of the (local) host “capable” of “playing the role of ...” within Windows' lmhosts file,
so that Windows host thinks that local host serves as that gateway.
And we also have to use ssh's -g,
which (from ssh's manual page) “allows remote hosts to connect to local forwarded ports”.
The direction of the port forwarding is from local to remote,
i.e. we will use ssh's -L
root@HayekA # env LD_PRELOAD=$HOME/.tconn/tconn.so \
/usr/local/bin/ssh \
-g \
-p 443 \
-L 866:classicgate.t-online.de:866 \
my_DynDNS_account@$($HOME/Computers.Software.Operating_Systems.Unix.Shell/nslookup_through_proxy.sh my_DynDNS_host.dyndns.org)
root@HayekA # env LD_PRELOAD=$HOME/.tconn/tconn.so \
/usr/local/bin/ssh \
-g \
-p 443 \
-L 866:classicgate.t-online.de:866 \
my_shuttle_account@$($HOME/Computers.Software.Operating_Systems.Unix.Shell/nslookup_through_proxy.sh esslingen.shuttle.de)
root@HayekA # env LD_PRELOAD=$HOME/.tconn/tconn.so \
/usr/local/bin/ssh \
-g \
-p 443 \
-L 866:classicgate.t-online.de:866 \
my_shuttle_account@194.95.249.240
T-Online's NNTP server news.t-online.de can only be reached on resp. through a host
simply said dialed in to T-Online.
The direction of the port forwarding is from local to remote,
i.e. we will use ssh's -L
root@HayekA # env LD_PRELOAD=$HOME/.tconn/tconn.so \
/usr/local/bin/ssh -p 443 \
-L 119:news.t-online.de:119 \
my_DynDNS_account@$($HOME/Computers.Software.Operating_Systems.Unix.Shell/nslookup_through_proxy.sh my_DynDNS_host.dyndns.org)
root@HayekA # env LD_PRELOAD=$HOME/.tconn/tconn.so \
/usr/local/bin/ssh -p 443 \
-L 119:news.gnus.org:119 \
my_shuttle_account@$($HOME/Computers.Software.Operating_Systems.Unix.Shell/nslookup_through_proxy.sh esslingen.shuttle.de)
This should be similar to connecting to an NNTP server.
I don't usually go this way,
as I would have to start the transconnect+ssh thing for every single e-mail that I send, resp. batch of e-mails to be sent together.
Also would I have to patch sendmail.cf
and tell it to use another dedicated local port (to be forwarded to that host outside via ssh).
And I would have to tell my e-mail software to use a different local SMTP port to connect to.
(You wouldn't just forward the local standard SMTP port to outside, would you?
Imagine what local system e-mail messages would be delivered to outside then!)
What a pain!
...
In simple words: instead of using an SMTP server out there,
we use a sendmail out there.
But because a shell is involved between ssh and sendmail,
which mangles sendmail's parameters like Roger Moore <Roger.Moore@yahoo.com>,
we whave to do a little transformation from $@ to ${a[@]},
where e.g. the above e-mail address gets replaced by a simple Roger.Moore@yahoo.com.
That does not actually change the respective e-mail within the e-mail,
but only does it give sendmail the pure and actual e-mail address it needs for delivery.
I actually encapsulated all that in a ~/comp.mail.sendmail/sendmail.sh.
And I set emacs/gnus's sendmail-program to ~/comp.mail.sendmail/sendmail.sh.
$
env LD_PRELOAD=$HOME/.tconn/tconn.so \
/usr/local/bin/ssh \
-p 443 \
my_shuttle_account@194.95.249.240 \
/usr/lib/sendmail \
"${a[@]}"
I actually only use this with fetchmail and esp. within ~/.fetchmailrc.
I found the recipe for using an IMAP server together with ssh for avoiding sending plain passwords
and also for encrypting the entire traffic
on fetchmail's home page.
I embedded that plugin string suitably into an /etc/inet.conf entry
and wrapped it with a little TransConnnect.
If I will ever use this (and I doubt it!!),
I will use this with fetchmail and esp. within ~/.fetchmailrc.
...
This should be similar to connecting to an NNTP server.
If the HBCI connection is to be made on a UNIX host itself, it is just as simple as that.
If the HBCI connection is to be made on a Windows machine instead,
this works a little bit like the Btx thing above,
as a UNIX host has to play the role of the HBCI server
and that UNIX host has to let other local neighbours (i.e. the Windows neighbour)
see its forwarded port via ssh's -g.
...
The direction of the port forwarding is from remote to local
(somebody outside will connect to a port outside,
and connecting to that port will actually be forwarded to somewhere within the (area surrounded by the) firewall),
i.e. we will use ssh's -R
The sample value of 5909 refers to
$DISPLAY=localhost:9
.
You may have noticed, that as 5900+x is beyond 1023,
everybody may offer such a port, even on a UNIX system,
and we don't need to be root in order to offer or forward that port.
$ env LD_PRELOAD=$HOME/.tconn/tconn.so \
/usr/local/bin/ssh -p 443 \
-g \
-R 5901:somewhere.on.the.lan:5909 \
my_DynDNS_account@$($HOME/Computers.Software.Operating_Systems.Unix.Shell/nslookup_through_proxy.sh my_DynDNS_host.dyndns.org)5901 is the port on the remote side, 5909 is the port on somewhere.on.the.lan .
-g is necessary, because we are not forwarding to a local port, but to a port somewhere else.
A VPN -- is that more than encrpyted tunneling over the Internet?
just google for VPN, SSH, and PPP
Olaf Titz's tiny perl script ssh-ppp
[18]
-- that's what I adapted for me
the Linux VPN-HOWTO
the VPN PPP-SSH Mini-HOWTO
you might also want to read this critical statemtent from the CIPE (see above!) corner, why PPP over SSH and similar solutions are not a good idea
No dynamic keys, just static keys, just what comes with SSH, if I understand it correctly.
But for you and me, isn't that already sufficient, slim, and just nice?!?
At least for limited and non-production use.
I even use Olaf Titz's ssh-ppp successfully over a proxy.
Harald Vogt's UNIX VPN PoPToP-slirp combo server
There are different reasons to run slirp as a substitute for an ordinary PPP server:
In another section I give a short description of how to run SLiRP on the far end. That description does not fully apply to our context here, but you are getting the picture.
The problem with Windows is, that if you are dialing a VPN connection, there is no Post Dial Terminal Screen, and thus not chance to launch pptpd and SLiRP on the far end. The “Security” tab of the connection properties just does not show the panel "Interactive logon and scripting", which in turn lists the “Show terminal window” switch. I will get this issue solved once ...
After employing WLAN-s for quite a while with just WEP in place and reading all these security warnings and suggestions, I finally decided to make use of a VPN in order to protect my Samba file server and VNC server machine, and I went for PoPToP, as I came across it first, and FreeS/WAN (an IPsec implementation for Linux) later looked like far too heavy.
SuSE Linux comes with a nice recipe to set up PoPToP: /usr/share/doc/packages/pptpd/README.SuSE
They also let you run a firewall protected PPTP-VPN with just SuSE Linux 8.2, not only with their Enterprise edition.
I want to describe my changes hereafter.
From the pptpd manual page, section description:
pptpd is the PoPToP PPTP daemon, which manages tunneled PPP connections encapsulated in GRE[19] using the PPTP VPN protocol.
/etc/ppp/options.ppp-pptpI changed the suggested name of the PPP options file for my PPTP set up;
this name is also to be found in the options line within /etc/pptpd.conf.
I call my PPTP server on host HayekA
HayekA-PPTP-server in the context of /etc/ppp/chap-secrets:
name HayekA-PPTP-server
After a while you will hurry to switch the debug option off,
as pppd (and pptpd) floods your syslog.
/etc/pptpd.confMy PPP options file name gets declared via:
options /etc/ppp/options.ppp-pptp
My localip and my remoteip-s (covering as many remote IP-s as possible with the SuSE-8.2 compile-time setting for MAX_CONNECTIONS -- not that I need that many, but ...):
localip 10.0.5.1 remoteip 10.0.5.2-101
After a while you will hurry to switch the debug option off,
as pptpd (and pppd) floods your syslog.
/etc/ppp/chap-secretsIn the host column you will find again the name of our PPTP server together with the user name and the password:
johayek HayekA-PPTP-server PASSWORD *
Alright, now that you know, that the authentication to the PPTP server is password based, i.e. not public key based, you might be frightened, that some bad guys could start testing on that password. I share that fear with you. Well, you can start checking your syslog file for messages like these:
Jul 10 22:26:08 my_pptpd_server pppd[4128]: No CHAP secret found for authenticating CLIENT Jul 10 22:26:08 my_pptpd_server pppd[4128]: MSCHAP-v2 peer authentication failed for remote host CLIENT Jul 11 22:46:58 my_pptpd_server pppd[4128]: MSCHAP-v2 peer authentication succeeded for CLIENT
So maybe you want to try this:
perl -ne 'm/^.{15} \w+ pppd\[\d+\]:.*(CHAP secret|MSCHAP-v2)/i && print' /var/log/messages
Obviously, the CLIENT may vary.
The first two lines occur, if there is no entry for CLIENT in your chap-secrets file at all,
i.e. no line with CLIENT as the value in the client column.
Just the 2nd line occurs, if somebody already guessed a valid client, here CLIENT,
and then he (or maybe you) entered an incorrect password.
If the intruder knows a valid client name and the correspondig secret, you will find the 3rd line -- or was that you properly authenticating?!
I actually think, that the intruder does not have that many guesses in a row, if your firewall does something like stateful inspection[20].
Yes, the firewall should run in quickmode, and in section 9a (“External services in QUICKMODE”) we change just these settings, i.e. we do not protect the VPN device, as it doesn't need firewall kind of protection:
# External services in QUICKMODE. FW_SERVICES_QUICK_TCP="pptp" # (For VPN firewall that is VPN gateway: 50) FW_SERVICES_QUICK_IP="50"
rcpptpd and rcSuSEfirewall2 need getting restarted, and that's it on the Linux side.
On the Win XP side ...
you “create a new connection” (I call it “HayekA-VPN-PPTP”) in “Network Connections” ...
... “using ... VPN”,
then you have tell it explicitly again, that this should be a “Virtual Private Network connection”,
then you specify the connection name (Windows says “Company Name”),
then you have to insist on, that Windows should not dial the initial connection,
and thereafter you specify the host name resp. IP addresss.
In my set up it is also quite important, that my Windows client's other TCP/IP requests go straight to the WLAN router and not first through the PPTP server, so in the “Advanced TCP/IP Settings” I tell it, that it should not “Use default gateway on remote network”.
After starting the new VPN connection I have to fine-tune the routes:
route add 10.0.0.0 mask 255.0.0.0 10.0.4.1 route add 10.0.5.0 mask 255.255.255.0 10.0.5.2
as Windows decides to route all 10.0.0.0 connections through 10.0.4.1, thus bypassing my own 10.0.5.0 network.
I really like my small firewalled PPTP-VPN. It wasn't just a 5 minute thing to set up, but now everything is sorted and clear.
I almost missed mentioning this: any running VNC server is also protected from deliberate calls from the LAN and can only get called through the VPN.
If the machine hosting the PPTP server talks itself through a WLAN device, things aren't very continuous by the nature of WLAN (connection stopping and resuming once in a while ...) and rcpptp needs getting restarted occasionally, but if just the client talks through a WLAN device, “my users” should be able to restart at least the VPN connection, I guess.
Another issue: the server side keeps sending data to the client. If you have to pay for data transmitted as for mobile Internet via GPRS or UMTS, then you will notice how expensive that is.