I recently started working on Sdump to solve some of my personal issues with 3rd party request bins. While I have been actively using SSH for all my career essentially, it has been interesting to actually build and run an actual SSH server.

I was showing someone the other day who deployed a private instance and couldn't pass SSH authentication. Here are a few things you might not know but will be great to know going forward:

Random SSH servers do not have to know you completely

When connecting to a new ssh server, your ssh agent essentially goes through each of your keys, sending each of them to the ssh server until one is successfully authenticated. The downside of this is it can lead to some form of enumeration on specific users. It is interesting how many users still have this as a default.

While Sdump now has a feature to block/fail the connection immediately when the key isn't expected, this is probably something you should take a look and fix locally

How to fix?

The fix to this is relatively easy and simple. Update your ssh config file to specify the ssh key to use for a specific host. Usually the file is at ~/.ssh/config. You ideally want to add the following:

Host *
  PubkeyAuthentication no 
  IdentitiesOnly yes

Host google.com
  IdentitiesOnly yes
  PreferredAuthentications publickey
  IdentityFile ~/go/src/ayinke-llc/sdump/.ssh/id_rsa

This snippet above requests all connections to the ssh server at google.com to always use that specific private/public key pair to connect. This gets rid of the enumeration issues.

Uniquely identifying users

One of the first things that came up after I launched the public hosted version of Sdump, I was extremely bothered about someone abusing the service and hammering the service. Ideally, the fixes to this is as follows:

• Uniquely identify each user when creating a url
• Provide a set of allowances per url or per account.
• On request ingestion, check the allowances and ratelimit if required

The easiest way to identify each user off the top of my head was to either provide a way to generate an api token which can live in ~/.config/sdump/config.yml. Or ssh ssh.sdump.app -t YOUR_API_TOKEN

Another way to do this is to use a form of dynamic url thing per user.

But either methods seem complicated, it turns out you can just easily retrieve the fingerprint of a public key and that is expected to be as unique as possible for my usecase.

In Go, this is as easy as:

import gossh "golang.org/x/crypto/ssh"

sshFingerPrint := gossh.FingerprintSHA256(key.PublicKey())

With this in place, I can decide in the future to implement some form of plan/allowances/billing system if i wanted to as users can be uniquely identified now

It is important to note that this can easily be worked around by using a different ssh key such as ssh -i ~/.ssh/oops.rsa -p 2222 ssh.sdump.app