[Feature request] Use ssh forwarded agent connection to access target hosts
Is it possible to implement use of ssh-agent-forwarding to access target hosts?
As far as i know, we may use ssh user@semaphore-host -A option.
With '-A' option the special socket will be created on semaphore-host (somewhere) - that allow to go target host from shell and authenticate there using home ssh private key (auth agent).
The semaphore (if allowed by the configurable option) could use that agent-connection to try to authorize access to the target host, if there are any of such sockets.
If implemented, there could be a case:
- no private keys put into semaphore
- when need to run a playbook (that runs on remote hosts) - just connect via ssh -A to the semaphore and access will be granted.
Probably duplicate for #1751
This is an important feature that should be in semaphore, not sure why we're left battling with annoying workarounds (see https://github.com/semaphoreui/semaphore/discussions/847)
With '-A' option
-A option is insecure, i don't recommend to use it (see ssh man) another alternative is target host ssh-copy-id which will prompt for the user password the first time interactively without an option for passing the password as an option argument.
So the only solution is to add an interface in semaphore that prompts for the target host password to be used every time a new target host is added for an ssh key.
The password would be used in combination with the sshpass package (which has to be pre-installed)
like this:
sshpass -p 'password' ssh-copy-id user@host -i /path/to/key.pub
or using env:
SSHPASS='password' sshpass -e ssh-copy-id user@host -i /path/to/key.pub
This way the public key will be sent to the target host for subsequent connections, no need of manual work (except for setting up the user and its permissions on the target host before adding it to semaphore).
Note: the example above uses ssh-copy-id thus will need the presence of the private key so it can check the pub key before sending it, if this is inconvenient then send the public key manually to the target host authorized_keys with plain cat + ssh (using sshpass)
If the usage of a third party package (ssh pass) is to be avoided then the solution in this bash script should be useful
TYFR!
With '-A' option
-A option is insecure, i don't recommend to use it (see ssh man)
IMHO, it is not the place we should be afraid of using -A option to ssh. Suppose, we have P-personal computer with private key, S-Semaphore host, and [T]- list of target servers we want to affect on. Without -A option, like it is being now, it is recommended to create standalone ssh key pair on S, put public key to [T] then run tasks from Semaphore with git-repoed ansible playbooks. Anyone who hacked S - gets access to any of [T]. With -A option, we establish preliminar (even manual?) connection from P to S, making possible to ansible playbooks to authenticate on [T] using ssh-agent socket and get access. Same in this case - anyone who hack the S get access to [T]. Threats are equal.
So adding possibility to use -A option will not add much insecureness to the Semaphore overall.
The only point that owner should remember - ssh keys should be distinct for different host groups. One pair should be for ansible playbook's access, another key pair - for (e.g) direct manual ssh access on other hosts.
Suppose, we have P-personal computer with private key, S-Semaphore host, and [T]- list of target servers we want to affect on. Without -A option, like it is being now, it is recommended to create standalone ssh key pair on S, put public key to [T] then run tasks from Semaphore with git-repoed ansible playbooks. Anyone who hacked S - gets access to any of [T].
Ideally semaphore should dump the key into a file and delete it after using sshpass to send the public key, it doesn't need it in a file during normal use obviously Plus if someone hacks into S he should be able to access target hosts even without the ssh key (through the agent / semaphore process / playbook creation/editing / database access / and more depending on what is available to him)
So adding possibility to use -A option will not add much insecureness to the Semaphore overall.
In the manpage i linked it describes the -A vulnerability as:
Agent forwarding should be enabled with caution. Users with
the ability to bypass file permissions on the remote host
(for the agent's UNIX-domain socket) can access the local
agent through the forwarded connection. An attacker cannot
obtain key material from the agent, however they can perform
operations on the keys that enable them to authenticate
using the identities loaded into the agent. A safer alter‐
native may be to use a jump host (see -J).
This isn't negligible in my opinion, that said a solution using sshpass of a custom bash script shouldn't take too much more time than using the -A flag I'm curious what others have to say about this, i'm personally OK with any good secure solution