I'd be curious whether there's any security concerns on this one. Could an attacker craft a message that gets access to execute commands into a client terminal?
This is not sshd, this is a golang binary that uses the stdlib ssh lib. You would have to either a) figure out how to escape out of a golang binary, or b) if the go code executes shell commands with some user provided text, trying to shell inject something in there.
yup, not an extensive list, but further demonstrative:
- terminal emulators are not security hardened clients against malicious actors
- ssh lacks PKI and is inconvenient so users never do prekeying in practice, so it's TOFU / zero server assertion in most practical cases (i.e. easy to mitm)
- ssh channel features are a constant concern, for server resources and for client features like agents, agents are easy to disable
- most ssh implementations don't scale that well, it wasn't ever really a goal to do so
- there are few tools for auditing and monitoring, unlike the common protocols/services/clients
fun for toys, but i wouldn't put credit card details in there, unlike some streamers started doing lately.
ssh definitely supports PKI, it's just not the standard workflow for individuals
ssh-keygen (1):
ssh-keygen supports signing of keys to produce certificates that may be used for user or host authentication.
Certificates consist of a public key, some identity information, zero or more principal (user or host) names and
a set of options that are signed by a Certification Authority (CA) key. Clients or servers may then trust only
the CA key and verify its signature on a certificate rather than trusting many user/host keys. Note that
OpenSSH certificates are a different, and much simpler, format to the X.509 certificates used in ssl(8)
It's also worth knowing about SSH clients that can use X.509 certificate keys as normal pre-shared keys with any SSH server, like PuttyCAC and built-in for macOS High Sierra and later.
While it supports serial numbers, expiration dates and key revocation lists, it does not allow certificate chaining. That means whoever signs keys for end users has implicit access to the master key.
I'm not talking about supporting public key cryptography, I'm talking about having a specific and usable deployment of a PKI. The closest thing SSH has is SSHFP, which depends on DNSSEC, which is according to many opinions, DOA.
Yeah, though SSH is already very mature at processing text, so it's a surprisingly good fit for a chat. I would also remember that any machine you SSH from is going to give the server some metadata like IP address, public keys (which aren't useful as creds but can be for tracking). Really fun little project though
SSH might be, but maybe not your terminal. Which the very least can possibly trick you using escape codes. Also, unless my memory fails me 'cat'ing an untrusted file isn't recommended for security reasons.
I'm also interested. Setting up a passwordless SSH account for some public service sounds like a good way to give your machine away to North Korean hackers, because you forgot to set someting in /etc/sshd to "no".
Is there a usable description somewhere on how to do this safely?
