Obviously the next step here is a fake SSH agent that allows logins to a little sandbox.

Probably a bad idea, one vulnerable service invites people to look for more.

Depends what we mean by sandbox. I wouldn't make a chroot the honeypot, but I don't see an issue with a program that just simulates a shell but doesn't allow exec or real fs access, for instance.

I'd be weary of that. Sandboxes have been escaped.

I don't think you would ever let them touch OS-level resources. There are plenty of third-party ssh server libraries where you just get a Reader and a Writer to the remote end. When they connect, you write "root@cool-computer# ". When they send bytes, you discard them, then print "root@cool-computer# " again.

While obviously accepting a TCP connection and allocating resources on your computer is more risky than just ignoring the connection, presumably it would be fun to do this, which is a good reason for doing something. You can set a memory limit, file descriptor limit, etc. and just crash if they're exceeded. You can run your little fake ssh daemon in gvisor and protect against attacks nobody even knows about yet. All in all, it would be pretty low risk, and also pretty interesting.

And the next beyond that is a sandbox that contains simulated data....

honeypots are obvious.