Set up a SOCKS proxy on 127.0.0.1:8080. This works by allocating a socket to listen to port on the local side, optionally bound to the specified bind_address. Whenever a connection is made to this port, the connection is forwarded over the secure channel, and the application protocol is then used to determine where to connect to from the remote machine. Currently the SOCKS4 and SOCKS5 protocols are supported, and ssh will act as a SOCKS server. Only root can forward privileged ports.
$ ssh -D 127.0.0.1:8080 10.0.0.1
where 10.0.0.1 is the remote host ip address. Dynamic port forwardings can also be specified in the configuration file ~/.ssh/config:
Host 10.0.01 DynamicForward 127.0.0.1:8080
You can then use tsocks or similar to use non-SOCKS-aware tools on hosts accessible from 10.0.0.1, for instance, 10.0.0.2:
$ tsocks rdesktop 10.0.0.2
Make services on the remote network accessible to your host via a local listener.
Remember that you need to be root to bind to TCP port
Example: Make MySQL service running on the remote host (on TCP port 3306) accessible by connecting to 3306 port on the SSH client system.
$ ssh -L 127.0.0.1:3306:127.0.0.1:3306 email@example.com
or in the config file:
LocalForward 127.0.0.1:3306 127.0.0.1:3306
Make services on your local system / local network accessible to the remote host via a remote listener.
Example: The SSH server will be able to access TCP port 80 on the SSH client by connecting to 127.0.0.1:8000 on the SSH server
$ ssh -R 127.0.0.1:8000:127.0.0.1:80 10.0.0.1
or in the config file:
RemoteForward 127.0.0.1:8000 127.0.0.1:80
It’s sometimes easier to configure options on your SSH client system in ~/.ssh/config for hosts you use a lot rather than having to type out long command lines.
Using ~/.ssh/config also makes it easier to use other tools that use SSH (e.g. scp and rsync). It’s possible to tell other tools that SSH listens on a different port, but it’s a pain.
Host 10.0.0.1 Port 2222 User user1 ForwardX11 yes DynamicForward 127.0.0.1:8080 RemoteForward 80 127.0.0.1:8000 LocalForward 3306 127.0.01:3306
The authorized_keys file lives in a user’s home directory on the SSH server. It holds the public keys of the users allowed to log into that user’s account without providing a password.
Go to SSH authentication without password using RSA key to know how to generate and use RSA authentication.
Caveat: The authorized_keys file might not work if it’s writable by other users. If you already have shell access you can “chmod 600 ~/.ssh/authorized_keys”. However, if you’re remotely exploiting an arbitrary file-write vulnerability and happen to have a weak umask, you may have problems.
If your SSH client is also an X-Server then you can launch X-clients (e.g. Firefox) inside your SSH session and display them on your X-Server.
$ ssh -X 10.0.0.1 $ ssh -Y 10.0.0.1 # less secure alternative - but faster
X11 Forwarding must be enabled in the config file:
ForwardX11 yes ForwardX11Trusted yes # less secure alternative - but faster