If you want to see each step of this process as it happens,
which can be an excellent tool to help with debugging when things go wrong,
try adding the verbose -v command to your command.
In this case,
we can see how SSH reads the system-wide ssh_config
file to apply its configuration,
and then establishes a connection with the remote host.
SSH then takes an inventory of available key pairs
in the client's home directory, and since nothing else was indicated,
enables SSH protocol 2 on both the local and remote machines.
SSH then receives a server host key and checks it against any keys associated
with the host IP address in the client's known_hosts file.
Next, since we've already added our client's public RSA key to the host,
we're told that our RSA key has been accepted and the session has been launched.
Finally,
session environment settings are established and
we're welcomed to our new session.
You can see the same process from anywhere on the network
using the Wireshark Protocol Analyzer tool.
On Linux, you can simply grab Wireshark from the repositories by name,
but it's an easy download for any operating system.
For this demo,
since I'm going to be SSHing into a virtual LXC container on my local system,
I'll specify the lxcbr0 network bridge,
which will narrow down the output we'll be shown.
In general,
since most internet connected computers send and
receive so much network traffic,
intelligently minimizing the traffic Wireshark shows you is a really
useful way to help you understand what you're seeing.
Now, I'll start Wireshark up and then get SSH going to see how it looks.
That quickly produced a few dozen entries, each its own separate packet.
You'll notice that a good number of these are predictably using the SSH v.
2 protocol and are travelling back and forth between
the container's IP address and 10.
0.
3.
1, which is the address of the network bridge,
or in other words, between the container and my own computer,
which is using the network bridge to connect.
Clicking on a particular packet and then expanding the frame
item will give us some important metadata,
including a detailed timestamp.
This can be useful if you're trying to identify exactly
which operation this output represents.
Closing the frame and then expanding the Ethernet 2 item gives us the MAC
addresses associated with the network interfaces at each end.
This too can be really useful for understanding exactly
which machines are involved here.
The Internet Protocol and Transmission Control Protocol items can show us how
these events appeared as they passed through layers 3 and 4,
Network and Transport, along their journey.
The SSH Protocol item, when expanded, shows us details for this specific packet.
Naturally, the contents of the packet are encrypted,
so there's not a whole lot we'll be able to do with it.
Since each packet actually contains only a very small
part of the whole transmission chain,
let's right-click on any of the SSH packets and select Follow TCP Stream to
get an overview of the entire chain in a single window.
This one seems to start with a record of the negotiation over protocols and
identification of the encryption methods that are available.
But then comes the session itself, which is displayed as total gibberish.
And that's a very good thing as it tells us that Wireshark is quite
helpless when it comes to understanding what actually happened as all
the important stuff was safely encrypted.
That's how things are supposed to look.
If your output is significantly different,
then it's probably a sign you should spend some quality
time digging through the details.
Of course,
on Linux systems you can also read through your system logs for information.
For a record of attempted logins to a server,
print the output of the var/log/auth.
log file, or on newer computer running systemd, journalctl.
In either case, you can grep for sshd to narrow down your search.
One final data source,
which can generate useful output from the perspective of the server,
is to run the ssh daemon on the server in debug mode
specifying an alternate port since the standard ssh port 22
will almost certainly already be in use.
Then try to log in from your client using the same port.
Having worked through the basic function of SSH and the various ways you
can access real-time data stream suitable for diagnosis,
it's now time to address some common connectivity problems and the troubleshooting tools you can use to identify and solve them.