Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Try to limit the number of SSH connections #54

Open
stevenroose opened this issue Jan 23, 2021 · 2 comments
Open

Try to limit the number of SSH connections #54

stevenroose opened this issue Jan 23, 2021 · 2 comments
Labels
enhancement New feature or request

Comments

@stevenroose
Copy link
Contributor

When someone uses a Yubikey to for their SSH key or when someone doesn't use ssh-agent, there are currently 4 distinct SSH connections, one in a first step and then 3 in a row:

🚀 ℹ️ [deploy] [INFO] Building profile `system` for node `XX`
warning: Git tree '/home/steven/projects/XX' is dirty
Enter passphrase for key '/home/steven/.ssh/XXXX': 
🚀 ℹ️ [deploy] [INFO] Activating profile `system` for node `XX`
🚀 ℹ️ [deploy] [INFO] Creating activation waiter
Enter passphrase for key '/home/steven/.ssh/XXXX': 
Enter passphrase for key '/home/steven/.ssh/XXXX': 
Enter passphrase for key '/home/steven/.ssh/XXXX': 
👀 ℹ️ [wait] [INFO] Waiting for confirmation event...

It might be the case that the latter 3 could be bundled into a single SSH command.

@notgne2
Copy link
Contributor

notgne2 commented Jan 25, 2021

This is a slightly difficult issue to tackle, the main SSH connections that should exist are:

  • using Nix to push the profiles to the server
  • running the activate command, for activating the profile (and ensuring safety with magic-rollback)
  • running the wait command, for the deployer deploy to know when activation has finished (by watching for the canary file to be created)
  • running the confirmation command

activate has to be distinct because we let it outlive any other processes so it can roll back if the deployment is not confirmed, and the confirmation command has to be ran on a separate SSH session than wait to make sure we can still initiate not just continue to operate existing SSH sessions.

Pushing has to be distinct for 2 reasons, first because it is simply using nix copy and we have no control over anything executed in that session, second because it is in a separate step, allowing us to push every profile to every server, before starting to activate any of them, so there is less of a delay between subsequent activations.

It should be possible to make activate signal to deploy that activation has completed, thus removing the need for the wait command, but going any further will probably be difficult.

@notgne2 notgne2 added the enhancement New feature or request label Jan 25, 2021
@notgne2
Copy link
Contributor

notgne2 commented Jan 25, 2021

I will also note that if lowering the amount of SSH connections is more important to you than having magic rollback, you can turn it off and there should only be 2 connections instead of 4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants