1

Right now our team can connect to servers via SSH public key authentication. Each team member has a private key on his PC in ~/.ssh/ and the public key is on the server in the authorized_key file.

A request has been made to authorize ssh connections to the servers only from the PCs given to each team member.

Indeed right now even though the team members have no root access to these PCs, they can theoretically copy the private key from the home folder and use it on other machines to connect to the servers. So my question was how to do this?

I read a lot of documentation and tested the approach that seemed best to me : Host-based authentication.

This seemed to be the perfect solution to my problem, each PC would have a private key in /etc/ssh/ that is not readable for anon-root user and that is used to authenticate the host in addition to the existing public key authentication configuration.

The problem I have is the hostname that is sent by the SSH client to the server. I noticed that depending on the network I am connected to, the hostname that is sent will be fooMachine.localdomain, fooMachine.home, fooMachine.

I used ssh -vvv user@ip and looked at the lines beginning with

debug2: userauth_hostbased: chost ...

to notice that.

The PCs will not always connect to the SSH servers from the same network, we don't have a VPN or static IP.

So all this means that on the SSH servers, I will have to declare the host that is connecting multiple times (fooMachine.localdomain, fooMachine.home, fooMachine) and it may happen that I am connected to a network where I will have another suffix after fooMachine and I won't be able to connect my servers.

How do I solve this? Or is my approach wrong ?

Note that I tried to force the hostname to something like fooMachine.test.com. After reboot, the hostname --fqdn displayed fooMachine.test.com but the hostname used by the SSH client was still fooMachine.localdomain.

I also tried wildcards in the shosts.equiv file on the ssh server where I declare the hosts that will connect to the server, but it didn't work. And after reading the source code it makes sense since wildcards (+ in rhosts style files) are ignored.

1
  • 1
    It sounds like your PC's are not (fixed) workstations but rather more mobile, like laptops? -_- You're acquiescing in this request where you should be challenging because: "You can't and shouldn't attempt to "improve" security by defining trusted clients when you don't have the conventional tools available to identify what your trusted clients actually are (i.e. clients restricted to a specific VLAN and/or IP-range and/or connected to VPN )" and without those conventional tools you're attempts are doomed.
    – HBruijn
    Commented May 16, 2023 at 13:37

2 Answers 2

1

The typical method to add restrictions to what is allowed when attempting to authenticate with particular private key, is via the relatively underused "options" field in a ~/.ssh/authorized_keys file on the server - specifically for your use-case would be the ability to configure/restrict from which hosts a particular keypair can be used with the from="pattern-list" option.

For example:

# ~/.ssh/.authorized_keys
from="10.80.0.0/14,192.168.1.2,hbruijns-workstation.internal.example.com" ssh-rsa AAAAB3NzaC1y***...***== hbruijn@serverfault

That for example only allows login with the matching private key only from hbruijns-workstation.internal.example.com, the IP-address 192.168.1.2 and/or any IP-address from the range 10.80.0.0/14.

As a further refinement you can place the ~/.ssh/.authorized_keys under control of the server admin to ensure that your team members don't override that restriction.

As I already commented and you already mentioned as well, that doesn't help you much when your network does not support the prerequisites for implementing a security model that depends on trusted clients:

  • you need to have a reliable method to identify your trusted clients.

When your clients do not get assigned a fixed IP and/or hostname this method won't work (but neither will any other).

So the request "to authorise ssh connections to the servers only from the PCs given to each team member" should be declined or countered with a request to for example get the required static IP-address assignments for your team member PC's, or for example a management network where your team members can connect to with VPN.

0

One solution to your problem could be to use the SendEnv option in the SSH client configuration file (/etc/ssh/ssh_config or ~/.ssh/config) to send a custom environment variable containing the hostname you want to use for host-based authentication. On the server side, you can use the AcceptEnv option in the SSH daemon configuration file (/etc/ssh/sshd_config) to accept this environment variable.

Here’s an example of how you can do this:

On each client machine, edit the SSH client configuration file (/etc/ssh/ssh_config or ~/.ssh/config) and add the following lines:

Host *
    SendEnv MY_HOSTNAME

On each client machine, set the MY_HOSTNAME environment variable to the desired hostname. You can do this by adding the following line to the user’s shell profile file (e.g., ~/.bashrc or ~/.zshrc):

export MY_HOSTNAME=fooMachine.test.com

On the server, edit the SSH daemon configuration file (/etc/ssh/sshd_config) and add the following line:

AcceptEnv MY_HOSTNAME

On the server, restart the SSH daemon to apply the changes. After completing these steps, when a user connects to the server using SSH, the MY_HOSTNAME environment variable will be sent to the server and can be used for host-based authentication.

2
  • Thank you for your reply. Unfortunately this doesn't seem to work for my problem. I put sshd on DEBUG3 to have traces and the env setting is done after the hostbased authentication step and after the autherized_key verification step. It seems to be set just before the shell session is started, so way to late for me. Commented May 16, 2023 at 13:04
  • 2
    @Christopher If a user can copy private key to their own PC, surely they can set a variable before running ssh ?
    – Archemar
    Commented May 16, 2023 at 13:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .