4 ms·
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 sig
by 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 agoSure, but couldn't a malicious SSH server use this key to proxy a connection to another opkssh server?
- EthanHeilman 2y agoNo, 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.