3 ms·

I gotta say, I love AuthorizedKeysCommand, it is the most clever configuration option I've seen in a protocol! If you just try to stuff a ID Token into an SSH

I gotta say, I love AuthorizedKeysCommand, it is the most clever configuration option I've seen in a protocol! If you just try to stuff a ID Token into an SSH key and use AuthorizedKeysCommands you introduce replay attacks because the SSH server can pull your ID Token out and stuff it into another SSH key and replay it to other SSH servers to impersonate you. Opkssh doesn't have this weakness because it used OpenPubkey [0]. The real trick here is OpenPubkey. OpenID Connect gives you ID Tokens which don't contain public keys. OpenPubkey tricks your OpenID Connect IDP into including a public key you choose in the ID Token it issues. This turns ID Tokens into certificates without requiring any changes to the IDP. This makes ID Tokens safe to use in SSH. [0]: https://github.com/openpubkey/openpubkey/ https://github.com/openpubkey/openpubkey/

aftbit 2y ago
How does this prevent replay attacks, either by a malicious SSH server proxying the auth flow from another machine, or by a malicious server pulling out the signed IdP claims and passing them to another OpenID Connect target?
- EthanHeilman 2y ago
  > a malicious server pulling out the signed IdP claims and passing them to another OpenID Connect target The signed IdP claims aren't a secret. In OpenPubkey, they function like certificate for the user's public key. This makes them useless for replay attacks in opkssh. The signed IdP claims are also scoped to a Client-ID specific for opkssh, so non-opkssh OpenID Connect services will reject them.
  - aftbit 2y ago
    Sure, but couldn't a malicious SSH server use this key to proxy a connection to another opkssh server?
    - EthanHeilman 2y ago
      No, the SSH server only learns your public key and a signature specific to the SSH server generated in the SSH handshake. A malicious server would need your private key to successfully authenticate to another SSH server.
ryao 2y ago
OpenSSH is full of clever ideas.

aftbit 2y ago

How does this prevent replay attacks, either by a malicious SSH server proxying the auth flow from another machine, or by a malicious server pulling out the signed IdP claims and passing them to another OpenID Connect target?

EthanHeilman 2y ago
> a malicious server pulling out the signed IdP claims and passing them to another OpenID Connect target The signed IdP claims aren't a secret. In OpenPubkey, they function like certificate for the user's public key. This makes them useless for replay attacks in opkssh. The signed IdP claims are also scoped to a Client-ID specific for opkssh, so non-opkssh OpenID Connect services will reject them.
- aftbit 2y ago
  Sure, but couldn't a malicious SSH server use this key to proxy a connection to another opkssh server?
  - EthanHeilman 2y ago
    No, the SSH server only learns your public key and a signature specific to the SSH server generated in the SSH handshake. A malicious server would need your private key to successfully authenticate to another SSH server.

ryao 2y ago

OpenSSH is full of clever ideas.