`ssh-agent` process abscence requires user intervenition

[wav3m1nd3d]

User is required to run manually

if [ -z "$SSH_AUTH_SOCK" ]; then
    eval $(ssh-agent -s) > /dev/null
fi
ssh-add "ssh-add "secrets/ssh/$CDE_HOST_SSH_KEYPAIR_NAME"

This issue is caused by script execution and thus non-inheritance of subshell's variables defined by ssh-agent and wrong configuration of user's host machine (ssh-agent service should be available), but it would be better for setup script to recover from this condition automatically.

Because this issue is host-dependant, it needs to be verified and solved on multiple platforms:

Verified:

• [X] Linux
• [ ] Macos
• [ ] Windows

Manually solved:

• [X] Linux: Solution
• [ ] Macos
• [ ] Windows

Solved:

• [ ] Linux
• [ ] Macos
• [ ] Windows

[wav3m1nd3d]

This issue is partially solved for Linux (Debian 12)

The following solutions are possible:

1. ssh-agent alternatives such as gcr-ssh-agent.service (gcr package)

   systemctl --user enable --now gcr-ssh-agent.service

   and setting of environment variable (in this example appending the following to ~/.bashrc)

   # gcr-ssh-agent
   SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/gcr/ssh"

2. Creation of a systemd service with:

   ~/.config/systemd/user/ssh-agent.service unit file

   [Unit]
   Description=SSH key agent
   
   [Service]
   Type=simple
   Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
   ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK
   
   [Install]
   WantedBy=default.target

   ~/.config/environment.d/ssh_auth_socket.conf environment variable config

   SSH_AUTH_SOCK="${XDG_RUNTIME_DIR}/ssh-agent.socket"

   and command to enable and start it

   systemctl --user enable --now ssh-agent.service

[wav3m1nd3d]

eval $(ssh-agent -s) isn't effective because environment variables like SSH_AUTH_SOCK get lost when script execution process exits.

An intuitive solution would be exporting these variables in parent processes, but bash prevents (natively discourages) this behavior due to obvious security concerns, and so should we.

Another more sane possibility in my opinion is finding the currently running ssh-agent process (environment variables possibly are possibly available in other processes) for example with this script, otherwise prompt user with helpful message to start ssh-agent in some way that's reachable by VSCodium and setup.bash script.

[wav3m1nd3d]

Disabled eval $(ssh-agent -s) in 4676e135d2b5d3e5e5bf6227a3e77a275286b2b8 commit