Why implement a zitified ssh

Background

I thought to put together a few points that help less technical people understand the importance. Am I missing anything? Does it make sense?

Mutual Trust
A standard SSH configuration implements strong identities via a public and private key. However, it fails to block unauthorised requests and fails to implement Mutual TLS natively.

Closed Ports
A standard SSH configuration relies on port 22 being open to facilitate an inbound connection. A stronger security posture is to only allow outbound connections, which is not possible using SSH today.

Peer to Peer
Accessing a remote server on a private subnet requires a range of extra changes to configure. A stronger security posture is to eliminate these steps by creating a direct connection regardless of the server’s location

Hiding Traffic
Standard configurations leverage the use of known ports which can be used to identify the source of traffic. A stronger security posture is to hide this traffic using common ports.

SSH definitely blocks unauthorized requests. As for mTLS, if you configure SSH for public key auth, it would be considered mTLS. If you rely solely on user/pwd, it's not. So that needs a bit of a caveat. I would HOPE most people opt for public key auth, but I'm sure not all of them do. This is why poorly secured ssh servers supporting user/pwd auth are hacked so quickly/easily.

Here, I might add on the whole management hassle and possible exposure to more people/devices you intend via cloud provider ACL. Lots of people would react to this with "i'll just whitelist my IP addresses" but I don't think you can do that easily/effectively for any and all situations. A zero trust solution guarantees that for you.

For Hiding Traffic, I call this "service inference" in my presentation. You can't make any inferences when you synthesize all your traffic through a single port using something like OpenZiti (not all zero trust solutions work this way, VPNs/proxies can and do though)

1 Like

Ahh. learning something new everyday.. I just realised this is what the fingerprint is for.. creating a public like certificate to facilitate the mTLS.. would that be right?

Good point.. its a less vigilant option..

in contrast, when a firm gets hacked .. the first thing they tell you is..

be more vigilant :slight_smile:

Ahh.. that is a much better way to describe it..

PS>. I will send a note with more details as to why I wanted to validate some of these points.. I just need to tidy up a few things first now

the fingerprint that goes into your ~/.ssh/known_hosts file is your chance to verify the certificate is “the one you expect”. That’s why when it changes ssh is very SCARY… and you get something like:

[user@hostname ~]$ ssh root@pong
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!

When you type ‘y’ for trust that remote server you’re initiating the FIRST half of ‘mutualTLS’. You’re instructing ssh to trust the fingerprint of that cert presented by that ssh server…

Then when you add your key to the authorized_keys file on the remote server, you’re forming the other half of that mutualTLS trust.

Now when YOU connect, ssh can first verify that you’re connecting to the server you think you are trying to connect to… and the remote server can verify the incoming connection is a verified user…

1 Like

Thanks .. I have found this very valuable information .. as in the past.. I just clicked yes.. and never really understood what it meant .. :slight_smile:

Just realised you use this command to check the fingerprint before you accept :slight_smile:

ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub

Thanks again.. I found this really helpful.

That’s gonna give you YOUR fingerprint, not the remote machine fingerprint. Unless you mean if you’re on the remote machine - at which point you probably ssh’ed there if it’s a cloud machine and already accepted the fingerprint? :slight_smile:

1 Like

Yes.. good point to clarify..

I can capture this information when I launch a new service.. so that I can keep it for reference during the first ssh.. I have not done this in the past.. and will aim to add this to do the todo list :slight_smile: