Port forwarding in Linux

To access a machine not directly accessible on network, port forwarding can be used from an accessible machine to the destination machine. 

One common scenario where port forwarding is useful is where a process, like web server, is on a machine with no x-window/browser and it is not directly accessible from the machine running the browser, but an accessible "gateway" machine is available in between.

The following can be run on the "gateway" machine:

ssh <user>@<gateway-host> -L <port>:<destination-host>:<destination-port> -g -N

As long as this process is running, gateway-host:port will show the content from <destination-host>:<destination-port>. 

Avoiding SSH delay

# Enable verbose mode in ssh to determine where the hang is

[local-host]$ ssh -v <remote-host>

It will result in the following:

debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to <remote-host> [<remote-IP>] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: loaded 2 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client <port1> <port2> none
debug1: kex: client->server <port1> <port2> none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '<remote-host>' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:33
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: password
root@<remote-host>'s password:

Sometimes the ssh appears to hang / wait for a while at the line in bold above. It is usually due to the UseDNS - default is yes. Disabling it and restarting sshd on the remote-host should fix this delay in ssh:

Add the following line in bold to /etc/ssh/sshd_config on remote-host:

#      UseDNS  Specifies whether sshd should look up the remote host name and
#      check that the resolved host name for the remote IP address maps
#      back to the very same IP address.The default is "yes".
UseDNS no

Restart sshd on the remote-host:

[remote-host]$ service sshd restart

SSH without Password

In order to ssh from Host1 to Host2 without password, the following needs to be done:

user1@Host1:~> ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user1/.ssh/id_rsa):
Created directory '/home/user1/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user1/.ssh/id_rsa.
Your public key has been saved in /home/user1/.ssh/id_rsa.pub.

If ~/.ssh doesn't exist on Host2 as user2, create one:

user2@Host2:~> mkdir -p .ssh
user2@Host2:~> chmod 700 .ssh

Append user1's public key to authorized_keys and authorized_keys2 in user2@Host2:.ssh/:

user1@Host1:~> cat .ssh/id_rsa.pub | ssh user2@Host2 'cat >> .ssh/authorized_keys'
user1@Host1:~> cat .ssh/id_rsa.pub | ssh user2@Host2 'cat >> .ssh/authorized_keys2'

user2@Host2:~> chmod 640 .ssh

Now ssh from user1@Host1 to user2@Host2 should be possible without password:
user1@Host1:~> ssh user2@Host2\

Avoid Host Verification

ssh -o "StrictHostKeyChecking no" user@host

Debugging

Set LogLevel to DEBUG in /etc/ssh/sshd_config
/etc/init.d/sshd restart
Then try to ssh, debug messages will be logged to /var/log/secure
PS: Once you have resolved the issue remember to switch back LogLevel to INFO and again restart sshd.