By default, you can launch an SSH session,
fire off a few commands,
and then forget all about your terminal window for hours or even
days thanks to the yes value of the TCPKeepAlive line in the
etc/ssh/sshd_config on your server.
That can be useful if you want to use the session to run a long-lasting
process like perhaps a very large archive backup operation.
However,
if you happen to be logging into your Linux server from a
Windows machine using PuTTY or WinSCP,
then you might find yourself unexpectedly facing dropped connections.
This could be because by default PuTTY and WinSCP don't enable KeepAlive.
Updating this setting is just a matter of inputting some positive
value in seconds in the PuTTY connections configuration window
and clicking the sending of null SSH packets radio button on a
WinSCP in Advanced Options.
Many of the most frustrating SSH problems seem to
revolve around misbehaving passwords.
For instance,
you might've set up passwordless access to a server
using key pairs as I described earlier,
but now you find yourself facing a password prompt.
What has probably happened is that SSH has somehow
failed to recognize your key pair.
One common cause for this is the file permissions assigned to your key files,
or even their directories.
Because opening up access to your private keys to anyone else besides
yourself would pretty much defeat the whole point of the keys,
SSH is really picky about this.
Therefore,
make sure that the only read and write permissions given
to your private keys is to the owner, you,
and that no rights are given to anyone else.
One way to do that on a Linux machine is to run change
mode against the file with a value of 600 in the puTTY
connections configuration window.
Updating this setting is just a matter of checking the enable box.
All private keys must have this value, even those in the etc/ssh directory.
The permission value of parent directories themselves should be 700.
Another password related problem is actually not related to passwords at all,
but figuring that out would require that we carefully
read the messages that SSH sends us.
It can happen that when logging into an SSH server host that
should allow passwordless access that you'll be prompted for a
passphrase; that's passphrase, and not password,
even if this dialog box does call it a password for some reason.
This time it's not the remote server that's asking for the added authentication,
but assuming you created a passphrase for your keys when you used ssh-keygen,
it's your own local client wanting to make sure that it's
really you asking for your private key.
Believe me; I'm very familiar with that terrible sensation in the pit of my
stomach when I realize that I'm expected to provide a passphrase or a password
that I haven't used or even thought about for months.
Which password did I use?
How can I recover access?
If you don't already,
I strongly recommend that you start keeping all of your passwords in a
well-encrypted software password vault like FPN2,
KeePass, or Gorilla.
If you log into a Linux server by way of multiple layers of VPNs,
you might find yourself the victim of freezing or timeouts
that seem to be associated with operations generating
relatively large streams of data, like X11 applications.
In this case,
if you've confirmed that people logging into the server from
within its LAN are not experiencing this problem,
the reason might be that the maximum transfer unit,
MTU values,
used by the network interfaces on both your client and server might be too high,
and the packets are being fragmented as they're sent between destinations.
The solution might be to set the MTU on both client and
server interfaces to the minimum value of 576.
On Debian or Ubuntu machines,
this can be done by simply adding a line reading mtu 576
to the etc/network/interfaces file.
As we mentioned earlier,
SSH servers store identifying fingerprints from all clients that
connect in the known_hosts file in your user's.
ssh directory.
Should a login attempt come from an IP address that's been used before,
but using a machine with an unfamiliar fingerprint,
SSH will worry that this might be man-in- the-middle attack where
someone on your network is trying to spoof the client's ID and gain
access to decryptions of your communications.
If you often launch and destroy VMs within your LAN,
which get their IP addresses from a relatively small DHCP pool,
it's quite possible that all the mixing and matching will
sometimes confuse SSH and cause it to block access.
As the warning message itself tells us, the solution is quite simple.
If you're confident that there's nothing dark and sinister going on,
you can simply delete the outdated entry from the known_hosts file using
ssh-keygen with the -f flag to point to the known_hosts file and the -r
and the IP address you'd like to remove.
Now SSH lets us log in without trouble.
Let's review what we've learned about SSH.
The seven layers of the OSI network model include layer 5,
the session layer, which is where the SSH and Telnet protocols work.
SSH sessions can be authenticated in one of three ways,
using the now largely deprecated rhost method via hosts.
equiv files, using public/private key pair authentication,
or through a password.
You can add a passphrase to the use of your private
keys when the key is generated,
and then through the ssh-add program employ the SSH agent to
automatically handle the passphrase on your local client machine.
SSH stores identifying data for each client that
logs in in the known_hosts file.
SSH server configuration is controlled through the
sshd_conf file in the etc/ssh directory,
and client behavior is managed by the ssh_conf file.
You can gather and view SSH session data to be used for troubleshooting using a
network sniffer tool like Wireshark and view an entire session log by selecting
Follow TCP Stream from the Wireshark context menu.
You can also use system logs on the client machine or run the SSH daemon
in debug mode on the server to get more useful data.
When troubleshooting SSH problems,
you should first make sure that SSH is installed and running on both client
and server and that you have the appropriate network connectivity that's
not blocked by overly strict firewall rules.
You should also make sure that you're logging in using the correct
username and password for this particular server.
To avoid timeouts, make sure that your SSH client is set for KeepAlive.
To avoid login problems,
you must make sure that the permissions for your private
keys allow access only for the owner.
Finally, if you experience packet fragmentation,
especially with complicated network architectures, try lowering the MTU value for both server and client network interfaces.