Secure Shell (SSH) is a cryptographic network protocol for operating network services securely over an unsecured network.
SSH was designed as a replacement for Telnet and for unsecured remote shell protocols such as the Berkeley rlogin, rsh, and rexec protocols. Those protocols send information, notably passwords, in plaintext, rendering them susceptible to interception and disclosure using packet analysis. The encryption used by SSH is intended to provide confidentiality and integrity of data over an unsecured network, such as the Internet, although files leaked by Edward Snowden indicate that the National Security Agency can sometimes decrypt SSH, allowing them to read the contents of SSH sessions.
On 6 July 2017 the government transparency organization WikiLeaks confirmed that the US Central Intelligence Agency had developed tools that can be installed on computers running Microsoft Windows or GNU/Linux operating systems to intercept SSH connections started by SSH clients on the compromised systems.
Here we have listed the best tricks that all hackers should know.
Of course, we use SSH to login remotely:
$ ssh user@hostname
And, if needed, we can specify a different port:
$ ssh -p 2222 user@hostname
Sometimes, if we have a lot of SSH keys in our
~/.ssh directory, we’ll often find that SSHing into servers with the intent of using a password results in a “too many authentication attempts” error. If we need to log into a server with a password, we can attempt to force password-based login. This will stop SSH from attempting to use your SSH keys first:
$ ssh -o "PubkeyAuthentication no" username@hostname
If you use AWS, and in other cases, you might get a PEM file to use as an identity. In this case, you might need to specify a specific identity file to use when logging in. We can do this with the
$ ssh -i /path/to/identity.pem username@hostname
You may need to set your permissions on the pem file so only the owner can read/write/execute it:
chmod 0600 identity.pemor
chmod u+rw identity.pem && chmod go-rwx identity.pem
Here’s something really powerful.
If you want to setup aliases for servers you access often, you can create an
~/.ssh/config file and specify each server you log into, along with the authentication method to use:
$ vim ~/.ssh/config Host somealias HostName example.com Port 2222 User someuser IdentityFile ~/.ssh/id_example IdentitiesOnly yes Host anotheralias HostName 192.168.33.10 User anotheruser PubkeyAuthentication no How aws HostName some.address.ec2.aws.com User awsuser IdentityFile ~/.ssh/aws_identity.pem IdentitiesOnly yes
So, there’s a few example entries you might find in the
~/.ssh/config file (you can have as many entries as you’d like).
Using a defined host (“alias”) is as easy as this:
$ ssh somealias
Let’s cover the options used above:
- HostName – The server host (domain or ipaddress)
- Port – The port to use when connecting
- User – The username to log in with
- IdentityFile – The SSH key identity to use to log in with, if using SSH key access
- IdentitiesOnly – “Yes” to specify only attempting to log in via SSH key
- PubkeyAuthentication – “No” to specify you wish to bypass attempting SSH key authentication
SSH can be used for tunneling, which is essentially port forwarding. There’s a few ways we can do this – Local (Outbound), Remote (Inboud), and some others (Dynamic and Agent Forwarding).
Local Port Forwarding
Local port forwarding is what you use when you need to tunnel through a server’s firewall or other limitation.
A common example is attempting to connect to a remote database which is either behind a firewall or is only listening to local connection. For example, MySQL only listens to localhost connections by default. You can’t remotely connect to it without editing the
my.cnf file and have it listen on all networks. There’s also a firewall preventing you connecting to MySQL’s port 3306 anyway.
Remote means any computer that isn’t yours, which includes virtual machines (guests) inside of your host computer
Assuming we have SSH access to the remote server, we can get around this by creating a tunnel into the server. What might that look like?
ssh -L 3306:localhost:3306 username@hostname
Let’s go over this:
-L– Setup local port forwarding
3306– The local port to forward
localhost:3306– Within the remote server, what address and port to forward traffic to. Since the MySQL server is on the remote server, we’re tunneling to the remote server’s “localhost” on port 3306, which MySQL is listening to.
username@localhost– The SSH username and host to connect to
I can then use my local client to connect to the remote server as if it’s a local one:
Now, I used the same port locally and remotely, but I could have specified a different local port to use:
ssh -L 3307:localhost:3306 username@hostname
Then my local mysql client would have to connect to port
3307, which would still tunnel to the remote server’s local
Remote Port Forwarding
Remote Port Forwarding is good if you need to share your local computer with others who are outside of your network.
To do this, we need a remote server all parties can reach. Something like a AWS or Digital Ocean server will do.
First, let’s pretend our local computer has a web server running on port
# On our local machine: $ curl localhost:8001 Hi!
We want our friends to see our website, which simply says “Hi!”. Let’s use a remote server to forward requests to our local computer:
# Still on our local machine: ssh -R 9000:localhost:8001 username@hostname
Let’s go over this command:
-R– Using remote port forwarding
9000– The remote server’s port to use (not our local server this time!)
localhost:8001– The local address to forward to. Since our webserver is on localhost port
8001, that’s what we specify here. (Yep, the order of those arguments changed for -R over -L!)
username@hostname– SSH access to the remote server
If our remote server’s IP address was
184.108.40.206, then our friends can access our website at
220.127.116.11:9000, which will forward to our local site at
Note: To accomplish this, your remote server’s firewall must not block port
9000. You may also need to edit
/etc/ssh/sshd_config and set the
GatewayPorts directive to
yes. (Don’t forget to restart SSH after any changes to
You can run commands remotely using SSH as well – in fact, this might be the easiest “trick” for using SSH.
When you run a command using SSH, you’re running the command on the remote server. However, any resulting output will be displayed in your terminal.
Let’s just run some simple commands on a remote server. The following will run
pwd command. We’ll see that it returns the default folder that we would be in after logging in. The we’ll run the
ls command to see the directory’s output:
# Run `pwd` command $ ssh -p 2222 username@hostname pwd /home/username
This is actually the basis of how some server provisioning tools work. In fact, Ansible is very similar – it will run commands over SSH on groups of servers (in series and in parallel).
Let’s see how that works on Ubuntu really quickly.
First install Ansible on a server that will be doing provisioning (not the one being provisioned):
sudo apt-add-repository -y ppa:rquillo/ansible sudo apt-get update sudo apt-get install -y ansible
Then, configure one or more servers in the
[web] 192.168.22.10 192.168.22.11 192.168.22.12
Save that file and then let’s run a command on all three servers!
$ ansible -k all -m ping -u vagrant
This will run “ping” on each server. You’ll get some JSON output saying if they were successful or not.
The flags of that command:
-k– Ask for password
all– All servers configured in
-m ping– Use the ping module
-u vagrant– Login with user “vagrant”, which will work if the hosts defined are other vagrant servers. Change the username as needed.
You can actually run any command using the “shell” module:
$ ansible -k all -m shell -u vagrant -a "apt-get install nginx"
-a "apt-get install nginx will run the given command using the “shell” module.
Here’s more information on running ad-hoc commands with Ansible!
Let us know in comments below if you have any other cool SSH tricks!