SSH - Httqm's Docs

When ~/.ssh/known_hosts is clear text

It's straightforward : just search your host's hostname or IP.add.re.ss in ~/.ssh/known_hosts with your favorite text editor / grep /

When ~/.ssh/known_hosts is hashed

ssh-keygen -F hostname -f ~/.ssh/known_hosts
ssh-keygen -F IP.add.re.ss -f ~/.ssh/known_hosts

There are situations —like working with Ansible— where naming hosts is paramount so that everything is organized, readable and explicit. This implies the whole team settles on a naming convention.

Alas, for the vision of one man lends not its wings to another man., the team members sometimes can't agree on such a convention, ending with :

half-the-team : naming hosts platformName_hostRole is fine
other half of the team : using the CMDB references that make no sense (like xyzABC_123-j_012) is "simpler" ()

However, nobody has to resign to having to use such poor names.

File	Single naming convention	Multiple naming conventions
Ansible inventory file Common to all team members, usually shared via Git.	apache ansible_host=platformA_apache mysql ansible_host=platformA_mysql	apache ansible_host=xyzABC_123-j_054 mysql ansible_host=xyzABC_123-j_012
~/.ssh/config Not shared with the team	Host platformA_* User kevin ProxyCommand ssh bastion -W %h:%p IdentityFile ~/.ssh/myPrivateKey AddKeysToAgent yes StrictHostKeyChecking no Host platformA_apache HostName 192.168.0.45 Host platformA_mysql HostName 192.168.0.46	Host platformA_* xyzABC_123-j_* User kevin ProxyCommand ssh bastion -W %h:%p IdentityFile ~/.ssh/myPrivateKey AddKeysToAgent yes StrictHostKeyChecking no Host platformA_apache xyzABC_123-j_054 HostName 192.168.0.45 Host platformA_mysql xyzABC_123-j_012 HostName 192.168.0.46

File

Single naming convention

Multiple naming conventions

Ansible inventory file

Common to all team members, usually shared via Git.

apache	ansible_host=platformA_apache
mysql	ansible_host=platformA_mysql

apache	ansible_host=xyzABC_123-j_054
mysql	ansible_host=xyzABC_123-j_012

~/.ssh/config

Not shared with the team

Host platformA_*
	User kevin
	ProxyCommand ssh bastion -W %h:%p
	IdentityFile ~/.ssh/myPrivateKey
	AddKeysToAgent yes
	StrictHostKeyChecking no

Host platformA_apache
	HostName 192.168.0.45

Host platformA_mysql
	HostName 192.168.0.46

Host platformA_* xyzABC_123-j_*
	User kevin
	ProxyCommand ssh bastion -W %h:%p
	IdentityFile ~/.ssh/myPrivateKey
	AddKeysToAgent yes
	StrictHostKeyChecking no

Host platformA_apache xyzABC_123-j_054
	HostName 192.168.0.45

Host platformA_mysql xyzABC_123-j_012
	HostName 192.168.0.46

SSH is not able to use a proxy in order to access external computers.

To do so, you'll need an extra application to tunnel TCP connections through an HTTP Proxy supporting the CONNECT method : here comes corkscrew.

setup :
apt install corkscrew
configure corkscrew :
echo 'proxyUser:proxyPassword' > ~/.corkscrew

Looks like corkscrew prefers when passwords (including special characters) are not urlencoded.
for privacy of your credentials :
chmod 600 ~/.corkscrew

configure SSH client by adding to ~/.ssh/config :

Host sshServer
	HostName 12.34.56.78
	User stuart
	IdentityFile ~/.ssh/myPrivateKey
	ProxyCommand corkscrew proxy.myCompany.tld proxyPort %h %p ~/.corkscrew

connect to sshServer :
ssh sshServer

not tested (yet!)
works when otherProxy.mycompany.tld asks no authentication

Host sshServer
	HostName 12.34.56.78
	User stuart
	IdentityFile ~/.ssh/myPrivateKey
	ProxyCommand connect-proxy -H http://otherProxy.mycompany.tld:proxyPort %h %p
	ServerAliveInterval 120

See : source, man page

When connecting to a new host, SSH adds its host key to its local known hosts list : ~/.ssh/known_hosts. The next time a connection is being open towards this host, SSH will compare its known key with the key advertised by the host it's currently connecting to :

if keys match, SSH recognizes the host as the one it previously connected to (and the connection establishes normally)
if keys don't match, something unexpected is happening and SSH will warn about it

The behavior described above is normal and expected : a host key is not supposed to change.
However, when experimenting with containers or virtual machines, it's pretty usual to build + use + destroy + re-build "hosts", and in such circumstances, SSH will send repeated warnings about hosts that have changed —which we are aware of and is not a security issue in this context.

Add this to ~/.ssh/config :

Host 172.17.*
	StrictHostKeyChecking no
	UserKnownHostsFile /dev/null
	LogLevel QUIET

I want to access numerous servers via SSH. These servers are spread over several distinct VLANs, each one having a single SSH gateway.
I must "SSH hop" on a gateway (like here) to reach each target server
I have distinct credentials for SSH gateways + SSH targets
I can NOT use SSH keys : login + password only
My workstation is a Debian "stable" where I can have root privileges
The solution must include secure storage of credentials

Colleagues working from Windows workstations found a solution to this with Tera Term, using it as a "PuTTY on steroids" .
I've not tried this solution, I just mention it for the sake of completeness.
It is not possible to store passwords in ~/.ssh/config (sources : 1, 2)
On my side, I already saved credentials in KeePass, and discovered it can do much more via some very interesting features :
- auto-type : sends simulated key presses to other applications
- field references : put references to data in fields of other entries

For reasons unrelated to the current article, I also have inter-operability constraints between GNU/Linux and Windows, and when saying KeePass, I mean :

for Debian : ~~KeePass2~~ KeePassXC
for Windows : ~~https://keepass.info/~~ https://keepassxc.org/

which both can handle .kbdx files.

The idea is to :

chain SSH logins from a single command-line (source) :
ssh -A t hopLogin@hop ssh -A targetLogin@target
store hosts + credentials in KeePass, avoiding repeating stuff thanks to field references
let KeePass build and auto-type the full SSH connection command, based on a template like :
ssh -At {REF:U@I:C03D4B434F400B4C843F682A994B0A02}@{REF:A@I:C03D4B434F400B4C843F682A994B0A02}{ENTER}{DELAY 100}{REF:P@I:C03D4B434F400B4C843F682A994B0A02}{ENTER}ssh -At {USERNAME}@{URL}{ENTER}{DELAY 100}{PASSWORD}
{whatever} placeholders will be replaced by the value of the named variable or key or action :
- USERNAME : username of the current entry
- REF:U@I:C03D4B434F400B4C843F682A994B0A02 : reference to the value of another entry (details)
- ENTER :
- ...

Let KeePass auto-type the SSH connection command :

open the KeePass vault and select the entry you'd like to auto-type
give the focus to the window that will receive the simulated keystrokes
give the focus back to KeePass and hit Ctrl-v to fire Perform Auto-Type
if this fails complaining The 'xdotool' utility/package is required for auto-type.
see the magic happen

During setup / tests, you may send simulated keystrokes to a text editor to see the generated SSH connection command and debug the auto-type template. Keep in mind your passwords will be echo'ed to screen.
Don't forget to connect manually to each SSH server (gateways + targets), since you'll be prompted to accept the SSH host keys.

don't mix sshpass and "auto-type" !

You may have landed here after having automated (or tried to) password-based SSH logins with sshpass. Your process may have lines such as :

sshpass -p 'password' ssh kevin@sshServer

If you plan to use any kind of "auto-type" feature, do NOT use it to generate SSH connection commands including sshpass, otherwise you will :

echo your password into the shell window (shoulder surfing)
store your password in your shell history
possibly disclose your password to other users of the current host if they can see your processes with ps
rely on a known low-security feature of sshpass

Actually, you don't even need sshpass anymore since the "auto-type" feature will "type" the password for you (for interactive logins only, I'm afraid ). As for KeePass, you'll end with auto-type sequences like :

ssh {USERNAME}@{URL}{ENTER}{DELAY 200}{PASSWORD}{ENTER}

The 'xdotool' utility/package is required for auto-type.

apt install xdotool

ssh-keygen -R 10.201.95.197

# Host 10.201.95.197 found: line 124
/home/kevin/.ssh/known_hosts updated.
Original contents retained as /home/kevin/.ssh/known_hosts.old

This works on clear text, hashed or mixed known_hosts files
To make sure the host key has effectively been revoked, you may have to run this command :
- several times
- both with a server's IP address and hostname
I guess my ~/.ssh/known_hosts is a mess because I re-use some IP addresses and hostnames on different machines (i.e. recycling IP/names on unrelated hosts, as for SSH).

Displaying a connection banner is fine when manually opening a connection to a server, but it's getting ugly / awkward when :

connecting to multiple servers in a one-liner / script
passing a command to the server(s) and trying to process the returned string(s)

From light to heavy weaponry :

Use SSH client's quiet mode :

ssh -q host command

Decrease verbosity :

ssh -o LogLevel=QUIET host command

Explicitly filter the unwanted banner :

ssh -q host command 2>&1 | sed -r '/banner/d'

This banner shouldn't be there, actually :

When you run ssh user@computer command, command is run non-interactively (source)
and there's no point in printing a connection banner to non-interactive shells (source)
so this should NOT receive a banner ()

Considering :

this network structure : workstation → sshHop → sshTarget
I can already run :
- from workstation : ssh stuart@sshHop (even though my local login isn't stuart)
- from sshHop : ssh stuart@sshTarget

it is possible to open an SSH session from workstation directly to sshTarget. To do so :

On workstation, add to ~/.ssh/config :

Host sshTarget
	User stuart
	ProxyCommand ssh %r@sshHop -W %h:%p

then, from workstation : ssh sshTarget

The Host directive accepts wildcards to fit various scenarios :

Host *.preprod.acmecorp.com
	

Host *.prod.acmecorp.com

Generate keys (details on SSH keys types) :

On Linux :

ssh-keygen -f keyName -b numberBitsKey

generates a private (keyName) + public (keyName.pub) key pair at the OpenSSH format. If not specified, keyName defaults to ~/.ssh/id_rsa
the type of key to generate can be specified with -t type (defaults to rsa for SSH protocol version 2).

generate a fixed-length Ed25519 key pair (~/.ssh/id_ed25519 + ~/.ssh/id_ed25519.pub): ssh-keygen -t ed25519

ssh-keygen -t ed25519 -a 100 -C "some comment"
generate a 2048-bit RSA key pair (~/.ssh/id_rsa + ~/.ssh/id_rsa.pub): ssh-keygen -t rsa

On Windows, for PuTTY :

You'll need PuTTYgen and this procedure to generate a private (keyName.ppk) + public (keyName.pub) key pair at the PuTTY format.

The public key is a text file such as :

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "this-is-my-key"
AAAAB3NzaC1yc2EAAAABJQAAAIBH+WrDPd3hTZMmZCIfn0olQYDkU3ay/GzSwsoq
gZe1NzNeUMIt45dYI6SoM2JTog8Qm04pyzb1FkB2N35TpNanY5B8fmtkVc/s4Dmp
7n++56VhU6gcceeuVTZuGwgJ17+CrmoAcBogHgR1Wwb32UJNsVXYs2TIzqlZa4n/
3GB0uw==
---- END SSH2 PUBLIC KEY ----

It contains a header line + a comment + the public key itself + a footer. You can convert it into the OpenSSH format :

with the dedicated utility
or manually, by editing it so that it looks like on a single line :
```
ssh-rsa public key comment (usually the owner ID)
```

Copy the public key to a SSH server

ssh-copy-id -i ~/.ssh/id_rsa.pub stuart@sshServer
This should automatically populate the ~/.ssh/authorized_keys file on the SSH server (read about some required chmod's)
Configure PuTTY accordingly.

Installing the key on an SSH server for the impatients :

As these commands use the ~ wildcard, run them as the user owning the ~ directory.

On the SSH server side :
mkdir -p ~/.ssh; touch ~/.ssh/authorized_keys; chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys
On the SSH client side :
cat ~/.ssh/id_rsa.pub | ssh kevin@myServer "cat - >> ~/.ssh/authorized_keys"

Log in using the key :

ssh kevin@myServer -i ~/.ssh/id_rsa
which can be aliased :
echo "alias ssh='ssh -i ~/.ssh/id_rsa'" >> ~/.bashrc && source ~/.bashrc
then :
ssh kevin@myServer

SSH - the HowTo's

How to check whether a given host is known to SSH (i.e. has its host key in ~/.ssh/known_hosts) ?

When ~/.ssh/known_hosts is clear text

When ~/.ssh/known_hosts is hashed

How can I assign several names / aliases to an SSH host ?

How to open an SSH connection through an HTTP Proxy with authentication ?

Alternate solution

How to avoid recording the host key into the known hosts list (~/.ssh/known_hosts) ?

Situation

Details

Solution

How to automate password-based SSH logins ?

Situation

Details

Solution

The idea is to :

Let KeePass auto-type the SSH connection command :

The 'xdotool' utility/package is required for auto-type.

How to revoke a host key from SSH's ~/.ssh/known_hosts file ?

How to hide the connection banner ?

Situation

Solution

How to hop through a SSH host ?

Situation

Solution

SSH : how to authentify using a public/private key pair ?

Generate keys (details on SSH keys types) :

On Linux :

On Windows, for PuTTY :

Copy the public key to a SSH server

Installing the key on an SSH server for the impatients :

Log in using the key :