Skip to content

One SSH key for the account that gets shared with each workspace on account #6794

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

Open
zpthree opened this issue Nov 19, 2021 · 12 comments
Open
Labels
component: local app feature: ssh meta: never-stale This issue can never become stale team: IDE team: webapp Issue belongs to the WebApp team type: feature request New feature or request

Comments

@zpthree
Copy link

zpthree commented Nov 19, 2021

Is your feature request related to a problem? Please describe

Nothing is broke but I do see it as a problem. It's a pain to have to add an ssh key to every new workspace, add it to github, add it to production server, add it to staging server, etc.

Describe the behaviour you'd like

It would be great if you we had one ssh key for each account that got used on each workspace on the account so we only had to worry about one ssh key. Coder is a service similar to Gitpod and this is something that they have which is really nice.

Coder - SSH keys

Describe alternatives you've considered

Additional context

@akosyakov
Copy link
Member

Is it in the context of VS Code desktop or generally for SSH access to Gitpod workspaces? We are working on new connectivity mode which does not require any tools/configurations anymore to connect. Will it be still useful? Basically you will be able to connect with ssh <workspaceId>:<workspaceSecret>@<workspaceHost>.

@zpthree
Copy link
Author

zpthree commented Jan 17, 2022

@akosyakov what I'm talking about is an SSH key at the user account level that gets shared among all the workspaces created on that account. That way you can add the public key to your different servers (staging, production, etc.), git accounts, and any other account you might access via SSH.

Specifically, for the workflow that I use I have different deployment commands that depend on SSH access, so what I'm currently doing is adding the private key as a GitPod variable and then setting it in the workspace manually that way so that anytime I create a new workspace, I can interact with the different servers without having to create new SSH keys and adding the new public keys to the servers. I can just add one public key to the servers and be able to interact with those servers from any new workspace.

@tkislan
Copy link

tkislan commented Jan 17, 2022

@zpthree I actually already do this exact thing
It can be easily done through tasks:

tasks:
  - name: Setup SSH
    before: |
      ssh-keyscan github.com >> "${HOME}/.ssh/known_hosts"
      if [[ ! -z "${USER_SSH_KEY}" ]]; then
        echo "${USER_SSH_KEY}" | base64 --decode > "${HOME}/.ssh/id_rsa"
        chmod 0600 "${HOME}/.ssh/id_rsa"
      fi

@zpthree
Copy link
Author

zpthree commented Jan 17, 2022

@tkislan Yeah this is what I'm doing now. It just seems like a cleaner solution would be for there to be a user SSH key tied to the user account that gets shared with all the user's workspaces. Doing it this way feels like a work around to me.

At a previous job we used Coder and this is how they do it.

From their docs:

The SSH Keys page is where you'll find the public key corresponding to the private key that Coder inserts automatically into your workspaces.

@axonasif
Copy link
Member

@tkislan @zpthree you guys should be able to achieve that across all workspaces with the brand new dotfiles feature of Gitpod!

Just define your SSH key inside a variable at https://gitpod.io/variables/ with */* scope.

Later create a dotfiles repo and have a install.sh script with the automation you want. Make sure to chmod 755 install.sh before committing the file.

For detailed info about dotfiles, please see:
https://www.gitpod.io/docs/config-dotfiles

@zpthree
Copy link
Author

zpthree commented Jan 17, 2022

@axonasif this is what we're both doing already. I'm currently manually adding a dotfiles repo and running an install.sh script that does this. The way Coder manages SSH keys is more painless. That's basically my point. It seems like a workaround to set it as a variable and then set it up with a script when Gitpod could automate that similar to how Coder does.

I'm mainly thinking about teams and other users here. I already have it set up so it doesn't bother me but it's not the most straightforward process.

@axonasif
Copy link
Member

@zpthree okay cool, didn't know about that 😅. This indeed is a workaround for now until we have a straightforward approach.

@loujaybee loujaybee added the team: webapp Issue belongs to the WebApp team label Feb 14, 2022
@loujaybee
Copy link
Member

loujaybee commented Feb 14, 2022

Thanks for raising @zpthree, we definitely can see where you're coming. Whilst there would be some interactions with IDE, this feels like something that's implemented more on workspace / web app level. CC: @jldec

Removing from IDE inbox for now.

@Diogenes4Sinope
Copy link

@zpthree thanks for the comment. Do you know if this can help me deal with working with two accounts? I have a work and personal account and will like to collaborate with others. But I cannot open a workspace on my Desktop VSCODE when added as a collaborator. Maybe the solution will be to generate new pub and private keys each time and use these to connect with each account?

@zpthree
Copy link
Author

zpthree commented May 31, 2022

@Diogenes4Sinope My guess is that you need a Gitpod account for each GitHub account, and that you can't open the repos connected to one of your accounts because the GitHub acount that is connected to Gitpod doesn't have access to those repos.

@stale
Copy link

stale bot commented Sep 9, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the meta: stale This issue/PR is stale and will be closed soon label Sep 9, 2022
@jonathanjfshaw
Copy link

I need something like this, both for cloning production database and getting composer packages.

@stale stale bot removed the meta: stale This issue/PR is stale and will be closed soon label Sep 16, 2022
@akosyakov akosyakov added the meta: never-stale This issue can never become stale label Sep 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: local app feature: ssh meta: never-stale This issue can never become stale team: IDE team: webapp Issue belongs to the WebApp team type: feature request New feature or request
Projects
None yet
Development

No branches or pull requests

7 participants