4

We can use public/private key pairs for client authentication when connecting to a SFTP server. Can we also have mutual authentication so the client also verifies a public key from the server?

Both my client and SFTP server are Linux boxes. I used ssh-keygen to generate a key pair for a client and then ssh-copy-id to give my server my client's public key. Would this also work vice versa from server to client? I can't test it out right now because I'll need to ask my sysadmin for access to the client server.

schroeder
  • 123,438
  • 55
  • 284
  • 319
J.Doe
  • 41
  • 1
  • 2
  • 3
    When you connect for the first time, it'll ask you if you trust the server's public key. When you connect again, if that public key has changed, your client will refuse to connect. Is that your question? – h4ckNinja May 04 '16 at 02:09
  • @Micheal I don't think that's the question – schroeder May 04 '16 at 04:07
  • @schroeder Yeah, I'm not terribly clear on what OP is asking. It looks like Trey was using the same line of thought I was. Edit: Aaaand now I get what the OP is asking. Rubber duck debugging at work. – h4ckNinja May 04 '16 at 04:47
  • @schroeder: What _is_ the question then? – SilverlightFox May 04 '16 at 09:56
  • @SilverlightFox it looks like a mutual authentication question – schroeder May 04 '16 at 14:39

3 Answers3

4

Authentication to SSH

Authentication takes two primary forms, username and password, and key-based authentication.

There is also an authenticity check performed when the client connects to the SSH daemon by confirming that the trusted public key has not changed by comparing the fingerprint that is in the trusted database known_hosts, and what the server presents. If these match, connection continues, the server challenges for authentication, and once validated, the full session is established.

What is mutual authentication?

Before talking about SSH, let's talk about mutual authentication in a typical implementation. A TLS mutual authentication presents certificates to both the server and the client, confirming identity. This is commonly used in B2B applications, such as API endpoints. This provides the benefits of PKI (encryption in transit, integrity checking, and revocation through CRL and OCSP responders) while providing authentication of the identity.

What about implementing that in SSH?

By default, this won't work. The SSH client connects to an SSH daemon. This would require that the server have client credentials on the client. Confusing? Let's take a step back.

User (You) -> SSH key -> Server

This is normal behavior. We want to flip that and establish trust in the reverse:

Server -> Different SSH key -> User (You)

This is dangerous. There are a few reasons why:

  • Compromise of the server would allow pivoting to the corporate desktop network, or to a user's home network. Either situation would be devastating.

  • ACLs in the enterprise should not allow this to happen. This makes pivoting and data exfiltration much simpler for an attacker.

Conclusion

This is possible, but rarely done, and is dangerous.

h4ckNinja
  • 3,006
  • 15
  • 24
  • Why would the server need client credentials (private key)? If SSH supports client certificate authentication, the server should only need the client's public key. – Alexander Taylor Mar 29 '22 at 21:38
3

If you run the following command on the SFTP server (assuming the correct path)
ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub

You will have an output similar to the following:

2048 7c:d9:68:a7:de:ad:26:12:34:56:78:00:4a:9b:a2:b9 root@localhost (RSA)

If you save this hash string with your client you can compare it upon first connecting or if you ever encounter the following message: 

The authenticity of host 'localhost (::1)' can't be established.
RSA key fingerprint is 3e:34:de:ad:55:55:55:66:89:ab:41:de:ad:46:20:16.
Are you sure you want to continue connecting (yes/no)?

You can then manually compare the two hashes and if they are different you will know whether or not you are not connecting to the correct server.

Note: Once you've connected successfully for the first time the client takes care of this comparison for you each time you connect and saves that data in the .ssh/known_hosts file for comparison.

That said, knowing the hash of the server key in advance would allow the client user to verify that he or she is connecting to the correct server.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Trey Blalock
  • 14,099
  • 6
  • 43
  • 49
0

There IS defined hostbased authentication method in ssh protocol, which does basically what is in the question.

This method needs to be explicitly allowed:

HostbasedAuthentication yes
EnableSSHKeysign yes

in ssh_config, but also on the server (but certainly not for everyone -- validated DNS name is a good start):

Host *.trusted.example.org
    HostbasedAuthentication yes
    EnableSSHKeysign yes

and then set up global known hosts in known_hosts files on client and server with valid public keys of the peers (they will basically substitute authorized_keys).

The last thing is /etc/shosts.equiv, which limits who can log in and from where.

I am not telling that it is good practice, secure or anything, but it exists. But using ssh certificates is much better approach.

Community
  • 1
Jakuje
  • 5,229
  • 16
  • 31