By default, you are probably uniquely identifiable: the SSH client sends your public keys, and sites like GitHub and GitLab publish the public keys for each account too. Someone made a demonstration SSH server a few years back that would greet you by GitHub username based on this, but I can’t immediately find it.
If you don’t specify a username, your local account name will be used and thereby disclosed.
Much more seriously, if you have the ForwardAgent option enabled, the remote server can impersonate you, using your SSH agent to log into any remote server. Don’t enable ForwardAgent globally, despite its convenience, unless you have an agent that requires manual action for every action; and be exceedingly leery of using it even on trusted servers, lest the compromise of one machine allow the compromise of everything. Consider ProxyJump instead.
I think this is sufficient regardless of configuration (but don’t trust me to be correct, I haven’t verified the actual traffic or anything):
ssh -a -o PubkeyAuthentication=no nobody@git.charm.sh
It’ll prompt you for a password, just press Enter, it’ll accept it.
Now of course using this will make you comparatively fingerprintable (though not identifiable) unless enough other people do it too. But then, they have your IP address, so—
If you want to skip the host key stuff, you can add `-o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no`, though it’ll emit a warning about adding the host key to the known hosts file every time.
Or just add a VM or user which specifically is used for such, and then destroyed. (By default, they still have your username and IP address, unless you take additional steps to obfuscate such)
You potentially send all your key IDs (ie public keys) your agent has. there are command line options to force your ssh not to use your agent in which case, barred any bugs in the ssh client, it’s like browsing to a domain in your browser.
I think it’s more of a privacy leak. E.g., the service could potentially figure out who you are if your public keys are tied to some other service, like GitHub.
If you ever manage to leak a private key it’s easier to track it back to you. There was a recent paper showing the ability to tie rather a lot of keys to the associated developers.
Regarding the concept in general, since it's just a screen with i/o you can't inspect its client-side code (the UI) nor what it does with your user input - but that can be more of a benefit for infosec reasons if you were to deploy this as an alternative to something like browser isolation[0] where you simply see what a remote browser sees without being able to inspect the contents of the page nor inject code.
If you don’t specify a username, your local account name will be used and thereby disclosed.
Much more seriously, if you have the ForwardAgent option enabled, the remote server can impersonate you, using your SSH agent to log into any remote server. Don’t enable ForwardAgent globally, despite its convenience, unless you have an agent that requires manual action for every action; and be exceedingly leery of using it even on trusted servers, lest the compromise of one machine allow the compromise of everything. Consider ProxyJump instead.
I think this is sufficient regardless of configuration (but don’t trust me to be correct, I haven’t verified the actual traffic or anything):
It’ll prompt you for a password, just press Enter, it’ll accept it.Now of course using this will make you comparatively fingerprintable (though not identifiable) unless enough other people do it too. But then, they have your IP address, so—
If you want to skip the host key stuff, you can add `-o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no`, though it’ll emit a warning about adding the host key to the known hosts file every time.