Difference between revisions of "SSH - agent"

From Helpful
Jump to: navigation, search
m
m
Line 1: Line 1:
 
{{SecurityRelated}}
 
{{SecurityRelated}}
<!--
 
 
{{stub}}
 
{{stub}}
  
  
tl;dr:
+
<!--
* a ssh agent is a vault protecting your private keys
+
* encrypted; usable only once you enter a master password
+
* presenting auth use (not the actual key value) to SSH clients that support agents
+
: more secure, also fairly convenient
+
  
  
When you want to use [[ssh keypairs]], you need the private key on each client side of each connection.
+
 
 +
When you want to use [[ssh keypairs]], you need a private key on each client side of each connection.
  
 
The simplest solution is to have them stored stored plainly in a file,
 
The simplest solution is to have them stored stored plainly in a file,
but that isn't great security in any multitenant setup,  
+
but that isn't great security in any multi-tenant setup,  
in that if anyone can read your files, they can read your private key.
+
in that anyone who can read your files can read out your private key.
  
  
An ssh agent
 
* lets you add keys to a pool that is encrypted on disk (protected by a master password), and has the key in unencrypted form only in memory
 
: and for the duration of a login session rather than always
 
  
* doesn't present that private key to ssh clients that want to authenticate
+
A ssh agent stores an encrypted form of private keys, and lets ssh clients use it for authentication (a specific protocol, connected via domain sockets).
: ...because in auth with keypairs, signing a message is enough to proves you have the private key
+
 
 +
 
 +
It does not give out that private key to an authenticating client,
 +
because it doesn't need to: the agent signing a nonce with the private key is enough to prove your system has the private key.
 +
 
 +
 
 +
 
 +
'''For interactive use''', ssh agents are convenient, in that login can be made quite transparent while that ssh agent is running.
 +
 
 +
 
 +
'''For scripts and services''', it can avoids some less-secure hacks like [[sshpass]].
 +
: Setting it up around services, sudo, and containers/VMs requires some more thought, though.
 +
:: largely because agents are typically run for the duration of a login session, rather than always
 +
 
 +
 
 +
 
 +
 
 +
 
 +
'''Agent forwarding''' is like a ssh tunnel for that agent socket - it will present a socket on the remote side that actually carries through to the originating side.
 +
 
 +
You might e.g. consider agent forwarding when dealing with [[bastion hosts]] (a single exposed SSH server that acts as a proxy to many firewalled internal ones), because it lets you automate the second step without having to store your keys on the bastion host in any form.
 +
 
  
* lets ssh clients connect to the agent via a [[domain socket]]
 
: making it fairly convenient for all a user's programs to use this, fairly transparently
 
  
  
Line 33: Line 45:
 
'''Security issues'''
 
'''Security issues'''
  
That "agent doesn't give the key" is good, because even when other people could connect to your agent's socket, they can't read out the keys.
+
It's not foolproof protection of the private key
 +
: you ''cannot'' read out the key via the agent protocol.
 +
: but dumping process memory (requires admin right) still gives you the key
 +
 
  
It also only works while it's running running - the thing that server asks to sign is random, so this is a one-time-use thing, so even inpersonators only get to do so once.
 
  
  
 
Impersonation
 
Impersonation
: anyone who can connect to your agent can impersonate you, so:
+
: anyone who can connect to your agent may no get the key, but can still impersonate you
: by default, use of keys is silent, so you won't notice such impersonation.
+
:: should only happen when things are misconfigured
 +
 
 +
: by default, use of keys is silent, so you usually won't notice such impersonation
 +
 
  
 
Alleviations:
 
Alleviations:
* don't use agents where you distrust root
+
* don't use agents on systems you don't trust your admins
  
 
* don't mess up the socket's permissions
 
* don't mess up the socket's permissions
Line 54: Line 71:
  
  
'''Agent forwarding''' is like a ssh tunnel for that agent socket - it will present a socket on the remote side that actually carries through to the originating side.
+
'''Agent forwarding''' comes with practical footnotes
  
You might e.g. consider agent forwarding when dealing with [[bastion hosts]] (a single exposed SSH server that acts as a proxy to many firewalled internal ones), because it lets you automate the second step without having to store your keys on the bastion host in any form.
+
In the bastion host example:
 +
* if you don't trust root, don't use agent forwarding
 +
* if that bastion host is ever compromised to root-equivalent rights, they can than impersonate everyone who's using agent forwarding.
 +
:: and now some of the alleviation above don't apply because it's not interactive.
  
However, if that bastion host is ever compromised, it comes back to the "impersonation is a thing" and in particular "don't trust root", and now some of the alleviation above don't apply because it's not interactive.
 
  
 +
Arguably a better alternative is ProxyJump
  
Arguably a better alternative is ProxyJump
 
  
  

Revision as of 16:02, 30 December 2021

Security related stuff.

Practical


Theory / unsorted



how to do a login system badly
how to do encryption badly
Disk and file encryption notes
This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)