On 7/18/22 3:28 AM, J. Roeleveld wrote:
Either on the client where the agent is running, but also on the
system I connected to.
I have always considered that there is enough sensitive data on the
client and that there are already enough things running there that I end
up considering the client a sensitive / secure system as a unit. This
seems to be especially true with servers hosting automation. But to
each their own.
As for the security of the forwarded agent, I've generally been okay
with root on the target system having access to the agent. Especial
when I have used different key pairs for different destination hosts and
/ or specify the from stanza in the authorized_keys file.
If you want to, you can specify how long, in seconds, that a key can be
used in an agent. So if you have a running agent, you can load a key
and specify that it can be used for up to two seconds. So even if
someone does compromise the target host and does talk to the agent, the
agent won't allow the key to be used and will behave as if the key
wasn't loaded.
You can also lock / unlock the agent on the source side as you see fit.
Unlock it for authentication, and then immediately re-lock it after
authenticating. Local commands and / or a local process using ssh
remote commands makes this more reasonable.
Aside: Backgrounded / multiplexed connections make running multiple
remote commands on a host a lot more expedient.
1) Log in to the remote host with a background connection.
2) Run multiple remote commands via "ssh <username>@<hostname>
<command>"
3) Log out of the remote host closing the background connection.
The business logic of the script lives on the client and all the
intermediate commands (#2) avoid the overhead of establishing a
connection and authenticating again.
But, I just noticed the following, which is hopeful, but need to read
up on this:
https://www.openssh.com/agent-restrict.html
Interesting. More reading.
Agreed, which is why I always stop and think when I see that.
;-)
Usually the answer is: "Oh, yes, I didn't access this host from my
laptop yet". But that is usually after the 2nd or 3rd connection
attempt with retyping the hostname and verifying the IP-address that
is resolved for it first.
I think I mis-took a previous statement to mean that you did something
to distribute the contents of the known_hosts file so that re-loads
would already be known. I guess I misunderstood.
--
Grant. . . .
unix || die
