Good point about the <token>@<host> format, I like it much better too.
You're right about tying tokens to host names, that would work. But you'd have to justify whether the extra complexity of multiple web servers preregistering tokens with a SSH front-end was worth it. Another approach would be embedding a static host identifier in the username as well.
Although my knowledge of the SSH protocol isn't complete, a related issue appears to be that servers prove their identity before clients send their usernames. That means servers sharing the same IP/port would also have the same host fingerprint.
It could be acceptable if all the services were run by the same organisation, but on a platform like Heroku it would be more of a challenge.
It wouldn't be too hard to extend the SSH protocol to include something like the HTTP Host-request header. In the protocol exchange section of the SSH RFC ( https://tools.ietf.org/html/rfc4253#section-4.2 ) the format described is:
In the comment section of the message, you could add something like "X-Host: hostname.wherever.org" and a smart SSH server could proxy the connection to the correct host. This happens before the key exchange occurs, so you'd still get strong authentication from having the right key.
I checked through the OpenSSH and Paramiko code, and both essentially ignore the comment section of the version exchange - everything between the first space and the CR/LF at the end. They does hold on to it for part of the DH key exchange, but they never try to interpret the bytes, so a modified client could keep sending the X-Host extension and stock OpenSSH would just ignore it.
You're right about tying tokens to host names, that would work. But you'd have to justify whether the extra complexity of multiple web servers preregistering tokens with a SSH front-end was worth it. Another approach would be embedding a static host identifier in the username as well.
Although my knowledge of the SSH protocol isn't complete, a related issue appears to be that servers prove their identity before clients send their usernames. That means servers sharing the same IP/port would also have the same host fingerprint.
It could be acceptable if all the services were run by the same organisation, but on a platform like Heroku it would be more of a challenge.