SSH

TCP port 22 has been assigned for contacting SSH servers.

SSH also supports tunneling, forwarding TCP ports and X11 connections;
file transfer (SFTP) or secure copy (SCP) protocols.
For browsing the web through an encrypted proxy connection with SSH
clients that support the SOCKS protocol.
For securely mounting a directory on a remote server as a file system on a
local computer using SSHFS.
Different internal protocols inside Ssh version 2:
Transport Layer Protocol
Connection protocol
Authentication Protocol
Specifies the order in which the client should try protocol 2 authentication
methods. This allows a client to prefer one method (e.g. keyboardinteractive) over another method (e.g. password). The default is:

gssapi-with-mic
hostbased
publickey
keyboard-interactive
password

Differences between ssh version 1 and ssh version 2

Diffie-Hellman key is used instead of the server key for sharing the
session key in version 2 protocol

No Rhosts support in ssh 2

SSH protocol version 1 only allows negotiation of the symmetric

encryption algorithm, all other things are hard corded(mac,
compression etc)

SSH 2 supports certificates for public keys used

SSH 2 server can dictate the client to use multiple authentication

methods in a single session to succeed. However ssh version 1 only
supports one method per session

SSH version 2 allows the change of session key periodically.

How does SSH Work
The client connects to the server via a TCP connection Like FTP, HTTP etc.
Then they send each other their version information and Protocol
information.
Next the server and client discuss what kind of Encryption, keys and
hashes they support.
Now the client sends the server an initialization message that includes the
message about the key exchange and a challenge message.
Now all the client does is listens for the server's response about the
request which will include the message about the server's key and a
challenge value that has been signed by the server's private key.
This is done to provide a validation that the packet could only come from
the server that sent it. (This makes the Ssh secure from man in the middle

attacks)
The client then checks the list of known hosts by searching
'~/.ssh/known_hosts' file. If the public key is listed, it automatically
assumes that the data is valid and the server is trusted. But if the public is
not listed here then the user is displayed with a prompt that asks them to
verify the finger print.
Now both the client and server have enough information needed to create
the master key that will encrypt the session and the communication
starts.

First time login:

[root@192-168-1-3 ~]# ssh -v 192.168.1.7
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.7 [192.168.1.7] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/identity-cert type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received

debug1: kex: server->client aes128-ctr hmac-md5 none

debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<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
The authenticity of host '192.168.1.7 (192.168.1.7)' can't be established.
RSA key fingerprint is 8d:21:68:7b:53:ce:61:c3:d7:0f:61:43:50:db:e2:ef.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.7' (RSA) to the list of known hosts.
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,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
reverse mapping checking getaddrinfo for 192-168-1-7.tpgi.com.au [192.168.1.7] failed POSSIBLE BREAK-IN ATTEMPT!
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_0' not found
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_0' not found
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_0' not found
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Next authentication method: password
root@192.168.1.7's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Last login: Thu Apr 2 18:30:28 2015 from 192.168.216.1
[root@192-168-1-7 ~]#
Second login:

[root@192-168-1-3 ~]# ssh -v 192.168.1.7

OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.7 [192.168.1.7] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/identity-cert type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<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 '192.168.1.7' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:3
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,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
reverse mapping checking getaddrinfo for 192-168-1-7.tpgi.com.au [192.168.1.7] failed POSSIBLE BREAK-IN ATTEMPT!
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_0' not found
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_0' not found
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_0' not found
debug1: Next authentication method: publickey

debug1: Trying private key: /root/.ssh/identity

debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Next authentication method: password
root@192.168.1.7's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Last login: Sun Apr 19 03:01:51 2015 from 192.168.1.3
[root@192-168-1-7 ~]#
Configuration
The SSH configuration file is called /etc/ssh/sshd_config.
#
#
#
#

The strategy used for options in the default sshd_config shipped with
OpenSSH is to specify options with their default value where
possible, but leave them commented. Uncommented options change a
default value.

#Port 22
#Protocol 2,1
#ListenAddress 0.0.0.0
#ListenAddress ::

Always force your systems to operate exclusively with version 2 by setting

the protocol statement in the /etc/ssh/sshd_config file to 2. Remember to
restart SSH to effect.
# File: /etc/ssh/sshd_config
#
Protocol 2

Port Change:
Change the Port line in /etc/ssh/sshd_config to mention 435 and remove
the # at the beginning of the line. Check to ensure SSH is running on the
new port:
[root@bigboy root]# netstat -an | grep 435
tcp
0
0
192.168.1.100:435
0.0.0.0:*
[root@bigboy root]#

Remote command execution

[root@smallfry tmp]# ssh 192.168.1.100 "uname -a"

Root Login Enable/Disable

LISTEN

[root@root ~]# vi /etc/ssh/sshd_config

Change this line:
#PermitRootLogin yes
Edit to this:
PermitRootLogin no
Limit User for SSH Logins
Open the /etc/ssh/sshd_config file.
Add an AllowUsers line at the bottom of the file with a space separated by
list of usernames. For example, user tecmint and sheena both have access
to remote ssh.
AllowUsers tecmint sheena
You can also explicitly deny particular users:
DenyUsers badness paula
Limit HOST for SSH Logins
Use TCPwrapper Service. The two important files are:
/etc/hosts.allow
/etc/hosts.deny
# /etc/hosts.allow
sshd: 1.2.3.0/255.255.255.0
sshd: 192.168.0.0/255.255.255.0
# /etc/hosts.deny
sshd: ALL

Firewall rule to Open/Block:

Using the iptables firewall commands you can do this as follows:

# All connectsion from address 1.2.3.4 to SSH (port 22)

iptables -A INPUT -p tcp -m state --state NEW --source 1.2.3.4 --dport
22 -j ACCEPT
# Deny all other SSH connections
iptables -A INPUT -p tcp --dport 22 -j DROP

Using SSH and SCP without a password

Configuration: Client Side

1) Generate your SSH encryption key pair for the file copy account. Press
the Enter key each time you are prompted for a password to be associated

with the keys. (Do not enter a password.)

[filecopy@bigboy filecopy]# ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key
(/filecopy/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in
/filecopy/.ssh/id_dsa.
Your public key has been saved in
/filecopy/.ssh/id_dsa.pub.
The key fingerprint is:
1e:73:59:96:25:93:3f:8b:50:39:81:9e:e3:4a:a8:aa
filecopy@bigboy
[filecopy@bigboy filecopy]#

2) These keyfiles are stored in the .ssh subdirectory of your home

directory. View the contents of that directory. The file named id_dsa is your
private key, and id_dsa.pub is the public key that you will be sharing with
your target server. Versions other than RedHat/Fedora may use different
filenames, use the SSH man pages to verify this.
[filecopy@bigboy filecopy]# cd ~/.ssh
[filecopy@bigboy filecopy]# ls
id_dsa id_dsa.pub known_hosts

3) Copy only the public key to the home directory of the account to
which you will be sending the file.
[filecopy@bigboy .ssh]# scp id_dsa.pub filecopy@smallfry:public-key.tmp

Configuration - Server Side

Here are the steps you need to do on the computer that will act as the
SSH server.
1) Log into smallfry as user filecopy. Create an .ssh subdirectory in your
home directory and then go to it with cd.

[filecopy@smallfry
public-key.tmp
[filecopy@smallfry
[filecopy@smallfry
[filecopy@smallfry

filecopy]# ls
filecopy]# mkdir .ssh
filecopy]# chmod 700 .ssh
filecopy]# cd .ssh

2) Append the public-key.tmp file to the end of the

authorized_keys file using the >> append redirector with the cat
command. The authorized_keys file contains a listing of all the public keys
from machines that are allowed to connect to your Smallfry account
without a password. Versions other than RedHat/Fedora may use different
filenames, use the SSH man pages to verify this.
[filecopy@smallfry .ssh]# cat ~/public-key.tmp >> authorized_keys
[filecopy@smallfry .ssh]# rm ~/public-key.tmp

From now on you can use ssh and scp as user filecopy from server bigboy
to smallfry without being prompted for a password.

Logging on the Client

First, I change syslog to create a separate log file for sshd. You can make
this change in /etc/rsyslog.conf. The local7.* already existed in my
configuration. I added the local6.debug line:
# Save boot messages also to boot.log
local7.* /var/log/boot.log
# SSH specific (Added by Stephen)
local6.debug /var/log/sshd.log
Then, I had to change the sshd configuration /etc/ssh/sshd_config. I set
the SysLogFacility to LOCAL6 to make the separate log file setting work
from above. Then, I changed the LogLevel to DEBUG.
# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#SyslogFacility AUTHPRIV
#LogLevel INFO
SyslogFacility LOCAL6
LogLevel DEBUG

Finally, restart both sshd and rsyslog to make the changes take effect.
sudo service sshd restart && sudo service rsyslog restart
This is a cool trick. If you open a shell to monitor the log, you can use the
tail command to print messages to the screen as they are written:
tail -f /var/log/sshd.log

SSH Tunnelling
With SSH tunneling the server computer can also receive data from other
computers on the client's network over the very same session. The client
is configured to listen on a specified TCP port and all data received on that
port will be automatically SSH encrypted and relayed to the remote
server. It is for this reason that SSH tunneling is also called SSH port
forwarding.
There are two types of forwarding:
Local Forwarding: Forwards traffic coming to a local port to a specified
remote port. This is also known as outgoing tunneling, as the tunnel is
established to the remote server.
Remote Forwarding: Forwards traffic coming to a remote port to a
specified local port. This is also known as incoming tunneling, as the
tunnel is established from the remote server.
As always it is best to explain these methodologies with some examples.

Introduction
1.

local: -L Specifies that the given port on the local (client) host is to
be forwarded to the given host and port on the remote side.
ssh -L sourcePort:forwardToHost:onPort connectToHost means: connect
with ssh to connectToHost, and forward all connection attempts to
the local sourcePort to port onPort on the machine
called forwardToHost, which can be reached from
the connectToHost machine.

2.

remote: -R Specifies that the given port on the remote (server) host
is to be forwarded to the given host and port on the local side.
ssh -R sourcePort:forwardToHost:onPort connectToHost means: connect
with ssh to connectToHost, and forward all connection attempts to
the remote sourcePort to port onPorton the machine
called forwardToHost, which can be reached from your local machine.

Additional options
-f tells ssh to background itself after it authenticates, so you don't
have to sit around running something on the remote server for the
tunnel to remain alive.

-N says that you want an SSH connection, but you don't actually
want to run any remote commands. If all you're creating is a tunnel,
then including this option saves resources.

-T disables pseudo-tty allocation, which is appropriate because

you're not trying to create an interactive shell.
Your example

The third image represents this tunnel. But the blue computer called
your host represents the computer where someone starts the ssh
tunnel, in this case the firewalled machine.
So, ask someone to start a ssh tunnel connection to your machine. The
command should basically look like
ssh -R 12345:localhost:22 YOURIP
Now the tunnel is opened. You can now connect via ssh to the firewalled
machine through the tunnel with the command
ssh -p 12345 localhost
which will connect to your own localhost (your machine) on port 12345,
but port 12345 is forwarded through the tunnel to port 22 of the localhost

of the firewalled computer (i.e. the firewalled computer itself).

Local port forwarding

Lets say that yahoo.com is being blocked using a proxy filter in the
University.
A SSH tunnel can be used to bypass this restriction. Lets name my
machine at the university as work and my home machine as home.
home needs to have a public IP for this to work. And I am running a SSH
server on my home machine. Following diagram illustrates the scenario.

To create the SSH tunnel execute following from work machine.

ssh -L 9001:yahoo.com:80 home
The L switch indicates that a local port forward is need to be created.
The switch syntax is as follows.
-L <local-port-to-listen>:<remote-host>:<remote-port>

Now
it
is
possible
to
browse
yahoo.com
by
visiting http://localhost:9001 in the web browser at work computer.
The home computer will act as a gateway which would accept requests
from work machine and fetch data and tunnelling it back. So the syntax
of the full command would be as follows.
ssh -L <local-port-to-listen>:<remote-host>:<remote-port>
<gateway>

The image below describes the scenario.

Here the host to yahoo.com connection is only made when browser

makes
the
request not at the tunnel setup time.
It is also possible to specify a port in the home computer itself instead of
connecting to an external host. This is useful if I were to set up a VNC
session
between work and home. Then the command line would be as follows.

ssh -L 5900:localhost:5900 home (Executed from 'work')

So here what does localhost refer to? Is it the work since the command
line is executed from work? Turns out that it is not. As explained earlier is
relative to the gateway (home in this case) , not the machine from where
the tunnel is initiated. So this will make a connection to port 5900 of the
home computer where the VNC client would be listening in.
The created tunnel can be used to transfer all kinds of data not limited to
web browsing sessions. We can also tunnel SSH sessions from this as
well. Lets assume there is another computer (banned) to which we need
to SSH from within University but the SSH access is being blocked. It is
possible to tunnel a SSH session to this host using a local port forward.
The setup would look like this.

As can be seen now the transferred data between work and banned are
encrypted end to end. For this we need to create a local port forward as
follows.
ssh -L 9001:banned:22 home

Now we need to create a SSH session to local port 9001 from where the
session
will get tunneled to banned via home computer.
ssh -p 9001 localhost

Remote Forwarding
The syntax for local forwarding relies on the -R SSH command line
qualifier which is configured like this:
-R bind-address:bind-port:remote-server-address:remote-port

The syntax is similar to that of the -L option. The bind-address and bindport are the IP address and TCP port on which the local computer will
listen for connections from its neighbors. If the bind-address isn't listed,
then the server will only accept connections from localhost. The remoteserver-address and remote-port specify the same options for the remote
server and are from the remote server's perspective. If you specify
localhost as the remote-server-address, SSH will be interpret it to mean
the Internet IP address of the remote server.
This can be useful in a number of scenarios. For example, you cannot
connect to your office workstation via VPN due to network maintenance,
but during this time your workstation still has access to the Internet.
Remote forwarding could provide you with access.

Here's another scenario. You are moving into a new Internet data center,
all the network gear has been configured, but the installation of the data
circuits has been delayed. This has caused the configuration of the servers
to be delayed. If one server wired to your network can get access to a
server on the Internet, via a wireless card, or otherwise, then remote
access to the data center could be achieved using remote forwarding.
Example 1: The local computer forwards any connection to localhost on a
specified port to a remote host. Forwarding occurs over a previously
established connection from the remote host. If we revisit our scenario
where VPN access will be down due to maintenance, the first thing to be
done is to configure your workstation at work to establish a remote
forwarding SSH session to your home server.
[root@work-001 ~]# ssh -R localhost:9999:localhost:22 root@home.my-website.org
root@home.my-web-site.org's password:
Last login: Sat Mar 17 21:15:36 2007 from 216.10.135.26
[root@bigboy ~]# ping localhost
PING bigboy (127.0.0.1) 56(84) bytes of data.
64 bytes from bigboy (127.0.0.1): icmp_seq=1 ttl=64 time=0.091 ms
64 bytes from bigboy (127.0.0.1): icmp_seq=2 ttl=64 time=0.082 ms
64 bytes from bigboy (127.0.0.1): icmp_seq=3 ttl=64 time=0.097 ms
64 bytes from bigboy (127.0.0.1): icmp_seq=4 ttl=64 time=0.078 ms

Here workstation work-001 creates an SSH session to server bigboy at

home. It also tells bigboy to use this session to forward data to work-001
when bigboy receives SSH connections to localhost on port 9999.
Remember, the remote-server-address of the -R option is from the remote
server's perspective (work-001). If you specify localhost as the remoteserver-address, SSH will be interpret it to mean the Internet IP address of
the remote server.
We have setup a ping session to ensure that there is constant traffic
between bigboy and work-001 over the connection so that any
intermediary firewall doesn't kill it due to inactivity.
When you arrive home, all you have to do is SSH to localhost on your
home system to gain access to your workstation at work.

[root@bigboy ~]# ssh -p 9999 root@localhost

root@localhost's password:
Last login: Sun Mar 18 15:50:16 2007 from 65.115.71.35
[root@work-001 ~]#

As you can see, remote forwarding can be both useful, convenient and
productivity enhancing.
Example 2: The local computer forwards any connection to it's NIC on a
specified port to a remote host. Forwarding occurs over a previously
established connection from the remote host.
This is more fitting for our limited connectivity data center scenario. In this
case the local computer can be accessed by anyone on the Internet and it
will forward any SSH connections it receives on the specified port to the
server in the data center with the wireless access. Here's how it's done:

Your local computer may be configured to only accept SSH

connections for remote forwarding on the loopback localhost interface.
Edit your sshd_config file and make sure the GatewayPorts setting is
set to yes.
#
# File: /etc/ssh/sshd_config
#
GatewayPorts yes

Restart the SSH daemon to activate the setting.

[root@netserver-001 ~]# systemctl restart sshd.service
Stopping sshd: [ OK ]
Starting sshd: [ OK ]
[root@netserver-001 ~]#

The next step is to establish the remote port forwarding session. Set
up a ping if you need constant activity on the link. In this case Internet
server is netserver-001.my-web-site.org.
[root@datacenter-001 ~]# ssh -R netserver-001.my-website.org:9999:localhost:22 root@netserver-001.my-web-site.org
root@netserver-001.my-web-site.org's password:

Last login: Sat Mar 17 21:15:36 2007 from 216.10.135.26

[root@netserver-001 ~]# ping localhost
PING netserver-001 (127.0.0.1) 56(84) bytes of data.
64 bytes from netserver-001 (127.0.0.1): icmp_seq=1 ttl=64
64 bytes from netserver-001 (127.0.0.1): icmp_seq=2 ttl=64
64 bytes from netserver-001 (127.0.0.1): icmp_seq=3 ttl=64
64 bytes from netserver-001 (127.0.0.1): icmp_seq=4 ttl=64

time=0.091
time=0.082
time=0.097
time=0.078

ms
ms
ms
ms

Here workstation datacenter-001 creates an SSH session to Internet

server netserver-001. It also tells netserver-001 to use this session to
forward data to datacenter-001 when netserver-001 receives SSH
connections on any interface IP address (*) on port 9999.

Now it's time to test it. From our home server bigboy, we can SSH into
server netserver-001 on port 9999 and get access to the data center.
[root@bigboy~]# ssh -p 9999 root@netserver-001.my-web-site.org
root@ netserver-001.my-web-site.org's password:
Last login: Sun Mar 18 15:50:16 2007 from 65.115.71.35
[root@datacenter-001 ~]#

Success! You have saved the day with your ingenuity.

Reverse Tunnelling with remote port forwarding
Lets say it is required to connect to an internal university website from
home.
The university firewall is blocking all incoming traffic. How can we connect
from home to internal network so that we can browse the internal site? A
VPN setup is a good candidate here. However for this example lets
assume we dont have this facility. Enter SSH reverse tunnelling.
As in the earlier case we will initiate the tunnel from work computer
behind the firewall. This is possible since only incoming traffic is blocking
and outgoing traffic is allowed. However instead of the earlier case the
client will now be at the home computer. Instead of -L option we now
define -R which specifies a reverse tunnel need to be created.

ssh -R 9001:intra-site.com:80 home (Executed from 'work')

Once executed the SSH client at work will connect to SSH server running
at home creating a SSH channel. Then the server will bind port 9001 on
home machine to listen for incoming requests which would subsequently
be routed through the created SSH channel between home and work.

Now its possible to browse the internal site

by visiting http://localhost:9001 in home web browser. The work will
then create a connection to intra-site and relay back the response to
home via the created SSH channel.

As nice all of these would be still you need to create another tunnel if you
need to connect to another site in both cases. Wouldnt it be nice if it is
possible to proxy traffic to any site using the SSH channel created? Thats
what dynamic port forwarding is all about.
Dynamic Port Forwarding
Dynamic port forwarding allows to configure one local port for tunnelling
data to all remote destinations. However to utilize this the client
application connecting to local port should send their traffic using
the SOCKS protocol. At the client side of the tunnel a SOCKS proxy would
be created and the application (eg. browser) uses the SOCKS protocol to
specify where the traffic should be sent when it leaves the other end of
the ssh tunnel.
ssh -D 9001 home (Executed from 'work')

Here SSH will create a SOCKS proxy listening in for connections at local
port
9001 and upon receiving a request would route the traffic via SSH channel
created between work and home. For this it is required to configure the
browser to point to the SOCKS proxy at port 9001 at localhost.

Configuring Forwarding with GUI Clients

You won't always have SSH command line access for the servers at both
end of a port forwarding connection. Sometimes a GUI is either easier to
use, or is your only option.
Most GUI clients will have SSH forwarding capabilities and it will be
configurable on each of your saved connections, not globally. The options
to do this should be found under the advanced properties or equivalent
tab and with your new Linux command line knowledge; the setup should
be relatively easy.
X11 forwarding
To enable X11 forwarding, first
the X11Forwarding and ForwardX11 options must be configured to yes for
both the client and server being connected to respectively. In your client
connection, add the -Y switch to the second invocation above, and
optionally the -C switch to also enable compression i.e:
user $ssh -YC -p CPORT <SUSERNAME@>localhost

The following is required for the forwarding of X11 connections from the server to client to
work:
The SSH daemon on the gateway machine must have TCP forwarding
must be enabled, otherwise X11 connections won't be forwarded:
FILE /etc/ssh/sshd_config

On the gateway

TCPForwarding yes
The xauth tool must be present on the server. Install netmisc/openssh with the X USE flag set to pull it in or install x11-apps/xauth.
X11 forwarding must be enabled in the server SSH daemon configuration:
/etc/ssh/sshd_config On the server
X11Forwarding yes
Troubleshooting SSH Port Forwarding
Here are a few symptoms that are easy to overcome:

If remote forwarding doesn't work from a remote server, but works

from localhost, then make sure you have activated the GatewayPorts
setting on your computer. If not, change it, restart the SSH daemon
and try again.
If you get a message like this stating that the address is already in
use, then you may have another port forwarding session already
started on the port or the port you intend to use for forwarding is
already in use by another application.
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 9999
Could not request local forwarding.

"Connection closed" messages like this one could be caused by

typing in an incorrect forwarding address.
ssh_exchange_identification: Connection closed by remote host

If you are attempting remote forwarding using your server's NIC IP

address and get this message, then it could be because the
GatewayPorts setting has been disabled. With local forwarding, it could
be caused by specifying an incorrect port on which the server should
listen.
[root@bigboy ~]# ssh -p 9999 192.168.1.100
ssh: connect to host 192.168.1.200 port 9999: Connection refused
[root@bigboy ~]

SSH port forwarding is a very useful tool that can provide you with a great
deal of versatility when administering your servers. It's always a good
thing to remember.

Debugging
Use the -v parameter to ssh will provide some output as to what is
wrong. In fact, you can maximize the debugging messages with -vvv.
ssh -vvv remoteuser@remotecomputer
Example Experience:
How to fix a slow SSH login issue on Linux
Question: When I try to connect to a remote SSH server, it takes very
long time (30 seconds to 2 minutes) before password prompt appears.
Why is SSH login so slow to start, and how can I get rid of long delay in

SSH login?
If you have to wait very long for SSH password prompt, there could be
several things that may go wrong. To troubleshoot the root cause of slow
SSH login, you can run ssh command with "-vvv" option, which will show
you what's happening behind the scene during SSH login. $ ssh -vvv
user@<ssh-server>

Here are possible solutions to the delayed SSH login problem.

Disable GSSAPI Authentication
One possible culprit (as indicated in the SSH client log above) is GSSAPI
authentication. During SSH login, SSH client goes through a series of
authentication steps, and one of them is GSSAPI authentication, where an
SSH server contacts a GSSAPI server to validate client authentication. On
Linux distros such as CentOS, GSSAPI authentication is enabled by default,
and GSS failure can add long delay in SSH session start.
To disable GSSAPI authentication on an SSH server, look for
"GSSAPIAuthentication" in /etc/ssh/sshd_config, and edit it or add the line
as follows.
$ sudo vi /etc/ssh/sshd_config
GSSAPIAuthentication no

Then restart SSH server:

$ sudo /etc/init.d/ssh restart (Debian, Ubuntu or Linux Mint)
$ sudo systemctl restart sshd (Fedora)
$ sudo service sshd restart (CentOS or RHEL)
Disable Reverse DNS Lookup
Another possibility for slow SSH login is reverse DNS lookup. On Linux
distros such as Ubuntu, when an SSH server receives a login request from
a client, the server performs reverse DNS lookup of the client's IP address
for security reason. If the reverse DNS lookup fails, lookup timeout will add
to SSH login delay.
To disable reverse DNS lookups on an SSH server, edit SSH server
configuration as follows.
$ sudo vi /etc/ssh/sshd_config
# add this line
UseDNS no
Then restart SSH server:
$ sudo /etc/init.d/ssh restart (Debian, Ubuntu or Linux Mint)
$ sudo systemctl restart sshd (Fedora)
$ sudo service sshd restart (CentOS or RHEL)
Q:12 How to limit the bandwidth used by scp command ?
Ans: We can limit the bandwidth used by the scp command using the -l
option as shown in the syntax.
#scp -l bandwidth_limit filename username@remote-host:/folder-name
bandwidth_limit is numeric to be specified in kilobits per second.