OpenSSH

Authentication protocol

Pubkey authentication steps

First unlock your ssh privkey with passphrase and add it to the ssh-agent by using ssh-add /path/to/privkey. Now the key can be used for ssh connections. The steps of the pubkey authentication as described in the protocol are the following:

Authenctication request is sent to the server. The request contains username, service name¹⁾, name of the method (pubkey), requested pubkey algorithm and the pubkey itself.
Daemon answers the request with failure if the algorithm isn't supported, or with an 'OK' to initialize the authentication.
Client creates a signature with it's private key and sends it to the daemon. The following components are used to calculate the signature: session ID, SSH_MSG_USERAUTH_REQUEST, username, service name, method name, TRUE²⁾, pubkey algorithm, pubkey.
Suitability test by the daemon if the pubkey can be used for authentication and checks it's format.
Verification signature is sent by the client
The authentication is finalized if step 4 and 5 both were successful and if the authentication isn't aborted by the client. This can be done by sending a new authentication request before finalization.

sshd_config

Access control

First matching wins
Configuring SSHd with AllowGroups and/or AllowUsers this will put it into deny by default mode.
Configuring stuff like AllowUsers <username>@<IP-address> is possible. Use it if possible.
Configuring Match blocks with multiple conditions is also possible:
Match Host <IPv4-Address>,<IPv6-Address> User <Name>

For testing sshd_config changes on remote it is possible to start another instance of SSHd on a on a different port with an alternate config file:
/usr/sbin/sshd -dD -f /etc/ssh/testing_sshd_config

ssh-keygen

Change the comment of existing keys

ssh-keygen -c -C "your new comment" -f <path/to/your/secret-keyfile>

It will prompt you for the passphrase and update the comments of both - the secret key and the public key.

Hashed known_hosts file

It is possible to use the known_hosts file in a hashed format instead of plain text format for better privacy. The command ssh-keygen -H moves the file ~/.ssh/know_hosts to ~/.ssh/known_hosts.old and creates a new one in the hashed format.

You can configure your client to always use hashed format for the file: HashKnownHosts yes

To delete an unneeded entry simply use the command
ssh-keygen -R <ssh-server>

SSHFP DNS records

  # ssh-keygen -r (<hostname>.)domain.tld

Snippets

Agent forwarding

Situation: 3 Machines

home
public shell
office

I have openend a tunnel with remote port forwarding from my office machine to a public shell server to make the office machine's ssh server accessible there - let's say on port 2222.

On my home machine I have created a keypair of id_rsa and id_rsa.pub and added it's pubkey to the authorized_keys file on my office machine - on my home machine I added id_rsa to the ssh-agent.

Then I ssh-ed from my home machine over the public shell server to my office machine, but without to stop with an interactive shell on the shell server. The command I used to do so is

ssh -i ~/.ssh/id_rsa -A -t  <user>@<shell-server> 'ssh -i id_rsa rtrulsen@localhost -p 2222'

With the -i option we instruct the client to use the id_rsa key for authentication, with -A to forward the agent. By doing this the client on the shell server uses the forwarded agent and can use the keys that were added to it. It drops a warning "Identity file <name> not accessible: No such file or directory.". This is because agent forwarding - of course - has got its own security risks, because an attacker could use the loaded keys. At least this is much more secure compared to copy the keys on a machine that's publicly accessible.

Remote port forwarding a.k.a. ReverseSSH

Terms:

Local machine: Your workstation from that you'd like to access the target machine
Shell server: The publicly reachable machine that you use as point in the middle of local machine and target machine
Target machine: The machine that you'd like to work on

1) Open a reverse ssh-tunnel from the target machine to the shell server

ssh -R 12345:localhost:22 (options) <account-name>@<shell-server>

-R is the option to open a reverse tunnel
22 is the port that your SSHd on the target machine is listening on.
12345 is the port you want later to use to access your target machine from the shell server.

2) From your local machine connect to the shell server

ssh <account-name>@<shell-server>

This is the usual way you connect to the shell server.

3) From the shell server connect to the target machine

ssh <account-name>@localhost -p 12345

Here <account-name> is the UNIX account that you have on the target machine and 12345 the previously defined port to access target machine over the reverse tunnel.

That's it.

SSH through tor with ProxyCommand and netcat

Prerequisites for this:

Access to a shell host somewhere to log in using ssh
A configured and running tor daemon on your local machine
netcat installed on your local machine

Example ~/.ssh/config entry without tor:

Host shell
  User rebeka
  IdentityFile ~/.ssh/shell
  Hostname shell.somedomain.tld

To open an ssh connection with the configuration block above you would fire up ssh shell in your shell.
To let this go through tor append the following to the ssh config block above:

ProxyCommand /usr/bin/nc -x localhost:9050 -X5 %h %p

-x means to use proxy protocol which could be SOCKS4, SOCKS5, or connect which is an HTTPS proxy and SOCKS5 is usually used per default.
-X5 specifies SOCKS5 explicitely
%h expands to the hostname to connect
%p expands to the port

A list of all available tokens with description can be found in the tokens section of ssh_config(5)

¹⁾

ssh-userauth is the service name for this protocol

²⁾

the TRUE constant

Table of Contents