We'll explore some very specific SSH-killing scenarios
and ways to fix them a bit later.
For now, however,
let's go through some of the really dumb and obvious
mistakes that we all make from time to time.
First of all, is SSH properly installed on both your client and server?
A full tank of gas won't help if your car doesn't have an engine on board.
So if running SSH from your client machine returns a Connection refused error,
it might be worth checking the status of SSHD on the server.
In my experience,
this is a particularly common problem when you're working with
multiple virtual machines of one kind or another.
Being able to instantly provision and launch a container or a cluster
node with just a couple of commands makes it easy to inadvertently
miss installing one of the basic tools, like SSH server,
that you'll need.
Getting a No route to host error could indicate that
the server itself isn't even running.
I guess that's usually a relatively simple problem to solve.
Of course,
the No route to host message could also indicate a
problem with your network connections.
All the obvious connectivity troubleshooting steps will apply here,
including pinging your remote server, and if that fails,
pinging a server you know is up, like 8.
8.
8, the easy to remember IP address for Google's DNS server.
Naturally, you should check your own network hardware,
including cable connections, switches, and routers,
and, of course, the hardware serving the remote server.
If all that checks out, and yet you still can't connect,
make sure that there aren't any server or client-side
firewall rules blocking traffic.
Remembering that the default SSH port is 22,
try running tcpdump against port 22 traffic between your local
network interface and your remote host address.
Here,
-n tells tcpdump to display the IP addresses in their original form
so we can identify them more easily in the output,
and -i points to my local network interface.
In this case,
we can see that my successful remote SSH login is producing all kinds of
packets moving back and forth between IP addresses,
representing my client and host machines and using port 22.
All those other data fields tcpdump is generating don't interest us right now.
Since successful SSH connections require packets moving in both directions,
you can run netstat - rn on your server to make sure
that both the U root is up and G, use gateway,
flags are displayed.
If there is something blocking you,
you'll need to look at your current firewall settings.
Finally, the more servers and layers of servers you're logged into,
the more likely it is that you'll find yourself entering the
correct password to start an SSH session,
but nevertheless find yourself facing a permission denied message.
What went wrong?
It's possible that you tried to log into an account called,
say, Admin,
but you're using the username for an account on a
different machine you're responsible for.
Another way you may encounter this is by accidentally
leaving out the username altogether.
SSH will try to use your username on the client machine,
but unless it happens to match a username on the host machine, the connection will fail.