Linux Networking Part 3

Secure file transfer

Some simple commands:

# scp file.txt host-two:/tmp
# scp joe@host-two:/www/*.html /www/tmp
# scp -r joe@host-two:/www /www/tmp

In Konqueror or Midnight Commander it is possible to access a remote file system with the address fish://user@gate. However the implementation is very slow.

Furthermore it is possible to mount a remote folder with sshfs a file system client based on SCP. See fuse sshfshttp://fuse.sourceforge.net/sshfs.html.

Tunneling

SSH tunneling allows to forward or reverse forward a port over the SSH connection, thus securing the traffic and accessing ports which would otherwise be blocked. This only works with TCP. The general nomenclature for forward and reverse is (see also ssh and NAT example):

# ssh -L localport:desthost:destport user@gate  # desthost as seen from the gate
# ssh -R destport:desthost:localport user@gate  # forwards your localport to destination
# ssh -X user@gate   # To force X forwarding

This will connect to gate and forward the local port to the host desthost:destport. Note desthost is the destination host as seen by the gate, so if the connection is to the gate, then desthost is localhost. More than one port forward is possible.
Direct forward on the gate

Let say we want to access the CVS (port 2401) and http (port 80) which are running on the gate. This is the simplest example, desthost is thus localhost, and we use the port 8080 locally instead of 80 so we don’t need to be root. Once the ssh session is open, both services are accessible on the local ports.

# ssh -L 2401:localhost:2401 -L 8080:localhost:80 user@gate

Netbios and remote desktop forward to a second server

Let say a Windows smb server is behind the gate and is not running ssh. We need access to the smb share and also remote desktop to the server.

# ssh -L 139:smbserver:139 -L 3388:smbserver:3389 user@gate

The smb share can now be accessed with \\127.0.0.1\, but only if the local share is disabled, because the local share is listening on port 139.

It is possible to keep the local share enabled, for this we need to create a new virtual device with a new IP address for the tunnel, the smb share will be connected over this address. Furthermore the local RDP is already listening on 3389, so we choose 3388. For this example let’s use a virtual IP of 10.1.1.1.

* With putty use Source port=10.1.1.1:139. It is possible to create multiple loop devices and tunnel. On Windows 2000, only putty worked for me. On Windows Vista also forward the port 445 in addition to the port 139. Also on Vista the patch KB942624 prevents the port 445 to be forwarded, so I had to uninstall this path in Vista.

* With the ssh.com client, disable “Allow local connections only”. Since ssh.com will bind to all addresses, only a single share can be connected.

Now create the loopback interface with IP 10.1.1.1:

* # System->Control Panel->Add Hardware # Yes, Hardware is already connected
# Add a new hardware device (at bottom).

* # Install the hardware that I manually select # Network adapters # Microsoft , Microsoft Loopback Adapter.

* Configure the IP address of the fake device to 10.1.1.1 mask 255.255.255.0, no gateway.

* advanced->WINS, Enable LMHosts Lookup; Disable NetBIOS over TCP/IP.

* # Enable Client for Microsoft Networks. # Disable File and Printer Sharing for Microsoft Networks.

I HAD to reboot for this to work. Now connect to the smb share with \\10.1.1.1 and remote desktop to 10.1.1.1:3388.
Debug

If it is not working:

* Are the ports forwarded: netstat -an? Look at 0.0.0.0:139 or 10.1.1.1:139

* Does telnet 10.1.1.1 139 connect?

* You need the checkbox “Local ports accept connections from other hosts”.

* Is “File and Printer Sharing for Microsoft Networks” disabled on the loopback interface?

Connect two clients behind NAT

Suppose two clients are behind a NAT gateway and client cliadmin has to connect to client cliuser (the destination), both can login to the gate with ssh and are running Linux with sshd. You don’t need root access anywhere as long as the ports on gate are above 1024. We use 2022 on gate. Also since the gate is used locally, the option GatewayPorts is not necessary.

On client cliuser (from destination to gate):

# ssh -R 2022:localhost:22 user@gate            # forwards client 22 to gate:2022

On client cliadmin (from host to gate):

# ssh -L 3022:localhost:2022 admin@gate         # forwards client 3022 to gate:2022

Now the admin can connect directly to the client cliuser with:

# ssh -p 3022 admin@localhost                   # local:3022 -> gate:2022 -> client:22

Connect to VNC behind NAT

Suppose a Windows client with VNC listening on port 5900 has to be accessed from behind NAT.
On client cliwin to gate:

# ssh -R 15900:localhost:5900 user@gate

On client cliadmin (from host to gate):

# ssh -L 5900:localhost:15900 admin@gate

Now the admin can connect directly to the client VNC with:

# vncconnect -display :0 localhost

Dig a multi-hop ssh tunnel

Suppose you can not reach a server directly with ssh, but only via multiple intermediate hosts (for example because of routing issues). Sometimes it is still necessary to get a direct client – server connection, for example to copy files with scp, or forward other ports like smb or vnc. One way to do this is to chain tunnels together to forward a port to the server along the hops. This “carrier” port only reaches its final destination on the last connection to the server.

Suppose we want to forward the ssh port from a client to a server over two hops. Once the tunnel is build, it is possible to connect to the server directly from the client (and also add an other port forward).
Create tunnel in one shell

client -> host1 -> host2 -> server and dig tunnel 5678

client># ssh -L5678:localhost:5678 host1        # 5678 is an arbitrary port for the tunnel
host_1># ssh -L5678:localhost:5678 host2        # chain 5678 from host1 to host2
host_2># ssh -L5678:localhost:22 server         # end the tunnel on port 22 on the server

Use tunnel with an other shell

client -> server using tunnel 5678

# ssh -p 5678 localhost                         # connect directly from client to  server
# scp -P 5678 myfile localhost:/tmp/            # or copy a file directly using the tunnel
# rsync -e ’ssh -p 5678′ myfile localhost:/tmp/ # or rsync a file directly to the server

This Information is from http://cb.vu