4 ms·

Note: you are not vulnerable if you're not doing agent forwarding (-A). Honestly, you probably should never do -A anyway; use -J (proxyjump) instead. https://

Note: you are not vulnerable if you're not doing agent forwarding (-A). Honestly, you probably should never do -A anyway; use -J (proxyjump) instead. https://www.man7.org/linux/man-pages/man1/ssh.1.html https://www.man7.org/linux/man-pages/man1/ssh.1.html https://userify.com/docs/jumpbox https://userify.com/docs/jumpbox

pcthrowaway 3y ago
There are situations where `-J` won't work. For example, if I'm on a remote server and I want to clone or pull from a private repository, or push to any repository In fact, VS code expects you to forward an agent when developing on a remote instance with the remote-ssh extension. I believe it uses it for syncing repo changes primarily I agree though that you should consider it insecure to forward a connection to a shared host if it has other users who are equally privileged, or more privileged
- gunapologist99 3y ago
  > There are situations where `-J` won't work. That is true, but actually you should avoid -A in those situations also. > In fact, VS code expects you to forward an agent when developing on a remote instance with the remote-ssh extension. I believe it uses it for syncing repo changes primarily That's the case if you're ever trying to initiate an SSH connection via Git from a remote host. That's because the actual SSH connection isn't being triggered on your desktop or laptop, where -J would do it, but because it's being initiated right on the remote server itself. Let's call the remote server VSCODE (your desktop-in-the-cloud), your laptop/desktop LAPTOP, and the remote repo GITHUB. So, the correct answer there is actually counter-intuitive: Generate a private key on VSCODE (not LAPTOP) for that GITHUB repo. This key will be used only on that originating remote server (VSCODE), never anywhere else. In fact, that repo key will ideally be scoped as tightly as possible in Github/Gitlab/etc. As a general rule of thumb, generate at least one SSH key for each "location" where you'll be logging into another location. Keep your connections point-to-point unless you can use proxyjump.
  - pcthrowaway 3y ago
    > Generate a private key on VSCODE (not LAPTOP) for that GITHUB repo. This key will be used only on that originating remote server (VSCODE), never anywhere else. Deploy keys are more secure in most situations, but I'm not convinced that generating a bunch of additional keys with write access to your repo is always more secure. Regardless, it doesn't really fulfill the same need of "get access to repo from cloud desktop asap". I work with 20-30 private repos at my company, and I don't have admin access to most of them (so I couldn't create deploy keys for them). That would need to be kicked up and down a request pipeline, for each user accessing remotely, for each host they're accessing it from. It's much easier to Get The Work Done if I just forward my agent. And sure, the company could maybe set up better practices (though again, I'm not even really clear on how much more secure it would be to generate untold numbers of deploy keys), but I'm more likely to get the axe for not producing fast enough than they are to make sweeping changes to their security practices.
    - gunapologist99 3y ago
      Then just create a key on that box and use it for all of your repos (add it to your github keychain); you're still much better off than with one key to rule them all (and one RCE to rule your laptop ha)
      - pcthrowaway 3y ago
        That's a good point, probably the best way to do this, but does require manual management steps for every VM you want to use (which is perhaps a feature)
  - lxgr 3y ago
    > Generate a private key on VSCODE (not LAPTOP) for that GITHUB repo. This key will be used only on that originating remote server (VSCODE), never anywhere else. This gives anyone compromising the server at a point in time persistent access to your Github repo. Ultimately, there's two or three different possible models here (transparent SSH proxying, agent forwarding, key-per-host), with different tradeoffs. Although transparent proxying is usually the safest, it doesn't always work and here's no one-size-fits-all.
- formerly_proven 3y ago
  VS Code forcing people to follow bad practice, I'm shocked, SHOCKED, I tell you.
yjftsjthsd-h 3y ago
> Honestly, you probably should never do -A anyway; use -J (proxyjump) instead. I want to copy files between servers, ex. `ssh -A serverA` then `rsync ./foo serverB:`. Is there a way to do that without `ssh -A`? (And obviously without creating an actual private SSH key on either server)
- gunapologist99 3y ago
  Yes. Create a temporary (or permanent) private key on server A and then put its public key in server B. That's the correct way to handle this situation, definitely not -A.
  - lxgr 3y ago
    This implies a much higher level of trust in a dev server than might be warranted, since an attacker can exfiltrate keys from that server and then permanently use them from elsewhere. Agent forwarding doesn't have that problem. > That's the correct way to handle this situation, definitely not -A. Maybe for your situation; certainly not for all. If agent forwarding was strictly inferior to ProxyJump/ProxyCommand, it would have been deprecated.

pcthrowaway 3y ago

There are situations where `-J` won't work. For example, if I'm on a remote server and I want to clone or pull from a private repository, or push to any repository In fact, VS code expects you to forward an agent when developing on a remote instance with the remote-ssh extension. I believe it uses it for syncing repo changes primarily I agree though that you should consider it insecure to forward a connection to a shared host if it has other users who are equally privileged, or more privileged

gunapologist99 3y ago
> There are situations where `-J` won't work. That is true, but actually you should avoid -A in those situations also. > In fact, VS code expects you to forward an agent when developing on a remote instance with the remote-ssh extension. I believe it uses it for syncing repo changes primarily That's the case if you're ever trying to initiate an SSH connection via Git from a remote host. That's because the actual SSH connection isn't being triggered on your desktop or laptop, where -J would do it, but because it's being initiated right on the remote server itself. Let's call the remote server VSCODE (your desktop-in-the-cloud), your laptop/desktop LAPTOP, and the remote repo GITHUB. So, the correct answer there is actually counter-intuitive: Generate a private key on VSCODE (not LAPTOP) for that GITHUB repo. This key will be used only on that originating remote server (VSCODE), never anywhere else. In fact, that repo key will ideally be scoped as tightly as possible in Github/Gitlab/etc. As a general rule of thumb, generate at least one SSH key for each "location" where you'll be logging into another location. Keep your connections point-to-point unless you can use proxyjump.
- pcthrowaway 3y ago
  > Generate a private key on VSCODE (not LAPTOP) for that GITHUB repo. This key will be used only on that originating remote server (VSCODE), never anywhere else. Deploy keys are more secure in most situations, but I'm not convinced that generating a bunch of additional keys with write access to your repo is always more secure. Regardless, it doesn't really fulfill the same need of "get access to repo from cloud desktop asap". I work with 20-30 private repos at my company, and I don't have admin access to most of them (so I couldn't create deploy keys for them). That would need to be kicked up and down a request pipeline, for each user accessing remotely, for each host they're accessing it from. It's much easier to Get The Work Done if I just forward my agent. And sure, the company could maybe set up better practices (though again, I'm not even really clear on how much more secure it would be to generate untold numbers of deploy keys), but I'm more likely to get the axe for not producing fast enough than they are to make sweeping changes to their security practices.
  - gunapologist99 3y ago
    Then just create a key on that box and use it for all of your repos (add it to your github keychain); you're still much better off than with one key to rule them all (and one RCE to rule your laptop ha)
    - pcthrowaway 3y ago
      That's a good point, probably the best way to do this, but does require manual management steps for every VM you want to use (which is perhaps a feature)
- lxgr 3y ago
  > Generate a private key on VSCODE (not LAPTOP) for that GITHUB repo. This key will be used only on that originating remote server (VSCODE), never anywhere else. This gives anyone compromising the server at a point in time persistent access to your Github repo. Ultimately, there's two or three different possible models here (transparent SSH proxying, agent forwarding, key-per-host), with different tradeoffs. Although transparent proxying is usually the safest, it doesn't always work and here's no one-size-fits-all.
formerly_proven 3y ago
VS Code forcing people to follow bad practice, I'm shocked, SHOCKED, I tell you.

yjftsjthsd-h 3y ago

> Honestly, you probably should never do -A anyway; use -J (proxyjump) instead. I want to copy files between servers, ex. `ssh -A serverA` then `rsync ./foo serverB:`. Is there a way to do that without `ssh -A`? (And obviously without creating an actual private SSH key on either server)

gunapologist99 3y ago
Yes. Create a temporary (or permanent) private key on server A and then put its public key in server B. That's the correct way to handle this situation, definitely not -A.
- lxgr 3y ago
  This implies a much higher level of trust in a dev server than might be warranted, since an attacker can exfiltrate keys from that server and then permanently use them from elsewhere. Agent forwarding doesn't have that problem. > That's the correct way to handle this situation, definitely not -A. Maybe for your situation; certainly not for all. If agent forwarding was strictly inferior to ProxyJump/ProxyCommand, it would have been deprecated.