Please cache results

[aws]

Please cache results

[LordAlfredo]

Thank you for the request. I will bring this up with our product management, but I would not get my hopes up. There are two angles to consider why not: security and product goals.

I will avoid getting too deep into the system threat model, but as part of key verification at some point the active key list must be processed. By doing all of this within the scope of the ssh daemon's memory, there is practically nothing for malicious software to manipulate - it would have to crack the daemon process memory to add an undesired key, which would mean your system would have to already be totally compromised. On the other hand, a cache introduces a new potential attack surface.

As for product goals, the main focus of EC2 Instance Connect is

• Simplify the process of managing ssh key handling for instances for end customers
• Enable a ssh "pseudo-session" to the instance using IAM credentials
• Enable scoping of ssh keys to a singular session
  I won't get into the full details of why a key is desired to be "single session" here, but there are a number of benefits from a security and auditing standpoint.

In an absolutely perfect world, we would not be doing the key timestamp piece that you've noted. Instead, a key would be trusted by the ssh daemon once and then never again (unless it was published through EIC a second time). The problem is, it turns out doing this is incredibly complex - if you check the instance's auth logs, you can even see that the ssh daemon pulls the set of available ssh keys multiple times. It's much more nuanced than just "trust this specific request ID once" and would either require a full-featured sibling daemon for sshd to hook into or would require deep changes to sshd itself. The 60 second expiration is an approximation for single-session scoping without needing to make these deeper, riskier changes to the ssh daemon (60 seconds in particular was chosen as sufficient time for all parts of the ssh handshake to complete in all testing).

[cpaelzer]

Thanks for the Answer @LordAlfredo - I can see the Threat Model POV here. Maybe it can be a long term goal implemented inside the ssh daemon itself (or plugin, or sibling daemon, or maybe even a pam module or something like it) which could grant the benefits of reduced overhead/latency while at the same time not adding the same additional attach surface that an on-disk cache of any kind would do.

[raharper]

What about making use of the kernel keyring to store the session data and timestamps needed to implement a cache?