HowTo/SecureShell

Introduction

SSH can be made to act as an encrypted proxy, forwarding packets sent a port at your computer to a remote computer through an encrypted tunnel. This is good if you don't (or can't) have I2P/Tor/FreeNet installed in your local computer, but still want to have the anonymity and security that these networks provide.

• local computer <--SSH--> remote computer <--I2P--> the I2P-network

Both SSH and I2P heavily encrypts the data passing through.

Because of the encryption by SSH between your computer and your remote computer, no one will really be able tell what you are doing on any end unless they have compromised any of the two computers in the ssh-tunnel. The ideal case is when you own both computers: The remote computer is your home computer, and your local computer is your laptop, for example.

Note: Somebody might still be able to tell that you are using SSH to route through I2P, by checking when the SSH and I2P traffic goes non-idle at the same time. Hosting a few services on the remote I2P or doing some work on the same SSH session might confuse such one.

What you need:

• A local computer with an ssh-client
• A remote computer with an ssh-server and an I2P-node
• Some UNIX-based OS, but it will probably work with Windows as well

Examples

People learn by doing, so...

This example can be used to make up the commands:

ssh -f -N -L [local_port]:[remote_host]:[remote_port] [user]@remote_host

The flags used are:

• -f: daemonize self (aka go to background) after authentication (like password reading)
• -N: don't execute a command (like a shell) at the remote
• -L [local_port]:[remote_host]:[remote_port]: Redirect traffic from this computer's [local_port] to the remote computer, which then relays it to its understanding of [remote_host]:[remote_port]. You can specify multiples of this.
  

For our purposes, the [remote_host] of "-L"s for I2P traffic will mostly be "127.0.0.1".

(If you are going to use an SSH connection for other things, it's advised to leave "-f" and "-N" flags out, as mixing your I2P-relayed SSH traffic with you-doing-things SSH traffic will confuse somebody watching the network.)

For example, the following command will redirect the port "4567" to the remote's port "4444" in the background:

ssh -f -N -L 4567:127.0.0.1:4444 my-remote-computer.org

(If requested, after typing your password) SSH will relay the connections in the background. You can set your browser's proxy to the port you selected (in this example it being "4567") and SSH will handle the rest.

Note: Unless you are using SSH with the local user used being root, you can't listen on ports lower than 1024, as the first 1024 ports are privileged and can be listened upon only by root.

Here are a few more examples:

• Port 9999 to remote's 6668, I2P's default IRC port:

  ssh -f -N -L 9999:127.0.0.1:6668 user@your-remote-i2p-computer.com

• Port 8080 to remote's 8118, Tor's HTTP proxy, while spawning a shell for whatever you do:

  ssh -L 8080:127.0.0.1:8118 user@your-remote-i2p-computer.com

Privoxy

If you don't want to make lots of relay-ports and just want to route everything through one port, you can use Privoxy (a filtering local proxy) on the remote.
These changes to Privoxy's config file will let you to use I2P, Tor, and Freenet from only one port:

#this directs ALL requests to the tor proxy
forward-socks5t   /               127.0.0.1:9050 .
#this forwards all requests to I2P domains to the local I2P 
#proxy without dns requests
forward .i2p localhost:4444
#this forwards all requests to Freenet domains to the local Freenet node 
#proxy without dns requests
forward ksk@ localhost:8888
forward ssk@ localhost:8888
forward chk@ localhost:8888
forward svk@ localhost:8888

Then (assuming Privoxy listens on 8080) an ssh command like

ssh -f -N -L 8080:127.0.0.1:8080 user@remote-computer.org

will let you to set the proxies of everything to "127.0.0.1:8080" and Privoxy over at remote will take care of which network to send it to.

(Copied from forum.i2p. Thanks Romster and sirup! See here (forum.i2p))

Using Windows

This is tested with a Windows computer connecting to a Linux box. You can use Plink for this (search for PuTTY on something like duckduckgo and download Plink from their web site).
In a command prompt:

plink -N -L 8080:127.0.0.1:8118 user@your-remote-i2p-computer.com

The command prompt of Windows doesn't let an application to go to background, so the "-f" won't do any good, and closing the prompt will drop the connection. It is a good idea to omit "-N" too and use this as an actual SSH session, or type the command into the Run dialog (Win+R).

This behaviour can also be seen on Linux, by putting a process to background (Ctrl+Z), then closing the shell the process was running under. The built-in command of "disown" or "nohup" from coreutils will prevent this from happening.

SSH over I2P

Setup tunnels on both ends

This section describes how to use SSH "through" I2P. This can be useful for remotely using your computer without anyone knowing, or when the computer can't be reached publicly (like behind a firewall, NAT, etc). This also doesn't require the SSH server to be listening on all addresses "0.0.0.0".

Note: If the SSH server and the I2P node are on different machines on the same network, it might be a good idea to still use listen-on-any "0.0.0.0", as a source IP of "192.168.X.X" will be denied by a strict-localhost listening.

The speed and reliability will be around slow/bad or close to normal, depending on several factors. If you can, play with setting like tunnel/backup quantity settings to make it better, at the cost of being less anonymous.
You can also use a "terminal multiplexer", aka a terminal front which can be detached and reattached. GNU screen (can also be used with Byobu) and tmux can be used for such purpose.

This example is a proof-of-concept, but not secure at all, see below.

1. On both client and server, open the web console, go to "Hidden services" menu and create the tunnels with the wizard.
2. On the server, add a "Server" tunnel to localhost:SSHPORT (example "localhost:22")
3. On the client, add a "Standard" tunnel to localhost:SSHPORT (example "localhost:9922")
4. Copy the "Local Destination Key" from the server tunnel into the field "Destination" on the client tunnel.
5. Start the both tunnels and try to connect from client via SSH:

   ssh -p9922 username@127.0.0.1

Recommended next steps:

1. If no connection from LAN or public clearnet is needed, configure the SSH server to listen only on localhost interface.
2. Applying the usual ssh security measures:
   1. Change SSH authentication method from password to publickey or OTP based.
   2. Disable root login via ssh and configure sudo if necessary.
   3. Add security by configuring fail2ban for SSH logins.

Warning: This example will release the LeaseSet of your server tunnel publicly, letting anyone in, with the only front being SSH's authentication. It is recommended to use encrypted LeaseSets to prevent anyone but you from reaching the server. See this blog post for an example for Java I2P routers.

Using tools for file transfer over SSH

With a working tunnel setup for establishing a SSH connection through the I2P network, it is also possible to use most of the SSH-based tools for file transfer and synchronization as usual.

TODO: examples about SFTP

Rsync

This command will copy the "server" directory from the remote server to your computer's "client" directory through I2P (assuming the client tunnel is listening on port 9922):

rsync -e='ssh -p 9922' user@localhost:"/mnt/dir/at/server" "/mnt/dir/at/client"

See also

• Username
• Password
• Secure password generator