Vscode-remote-release: Incompatibility with pam_ssh_agent_auth due to $SSH_AUTH_SOCK symlink

[Friendly0Fire]

• VSCode Version: 1.42.0-insider
• Local OS Version: Windows 10.0.19041
• Remote OS Version: Ubuntu 18.04 LTS
• Remote Extension/Connection Type: SSH

Steps to Reproduce:

1. Install and configure pam_ssh_agent_auth as you normally would.
2. Open a shell within VSCode.
3. Attempt to use SSH auth for sudo; password is still requested.

Additional Details:

This seems to be due to an unresolved incompatibility between pam_ssh_agent_auth and using a symbolic link for the socket set in $SSH_AUTH_SOCK. First, enabling debug mode for pam_ssh_agent_auth shows the error "error: ssh-agent socket has incorrect permissions for owner". Second, running the command
export SSH_AUTH_SOCK="$(readlink -f $SSH_AUTH_SOCK)"
within the shell before attempting to use sudo solves the issue systematically.

As part of connecting to a server, VSCode replaces the initial $SSH_AUTH_SOCK with a symbolic link. Could this be enabled or disabled with a configuration setting? Alternatively, could there be a setting for running our own commands on connect after the $SSH_AUTH_SOCK variable is changed?

[roblourens]

We use a symlink because the actual SSH_AUTH_SOCK will change if the connection ends and you reconnect. When that happens the actual SSH_AUTH_SOCK in your terminal environments would become obsolete. I can add a setting to disable this but that would be the tradeoff.

Do you know what the correct permissions for the symlink would be? I would rather set those correctly if possible.

[chriscpritchard]

Seems to be related to having sticky bits set on /tmp - https://unix.stackexchange.com/questions/253959/root-cannot-connect-to-symlinked-socket-of-other-user & related oh-my-zsh bug https://github.com/ohmyzsh/ohmyzsh/issues/4763

Ideally, best practice might be to test for $XDG_RUNTIME_DIR (https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) and store it in there (which should have 700 permissions, so not face this issue), and if that environment variable doesn't exist store it in home (maybe ~/.vscode-server-insiders/tmp, that's cleared on application close and opening), that way, systemd distributions store it in the location designed for that purpose, and for non systemd distributions, it's stored somewhere that doesn't face this bug, but still makes sense, the XDG spec suggests:

If $XDG_RUNTIME_DIR is not set applications should fall back to a replacement directory with similar capabilities and print a warning message. Applications should use this directory for communication and synchronization purposes and should not place larger files in it, since it might reside in runtime memory and cannot necessarily be swapped out to disk.

[roblourens]

That makes sense.

[Friendly0Fire]

I can confirm that the problem is with the sticky bit and fs.protected_symlinks. Disabling it fixes the issue, though it would be preferable to relocate the symbolic link.

[chriscpritchard]

Thanks for sorting so quickly - do you know when it's likely to wing its way into insider builds?

[roblourens]

It will be in the nightly version of the extension tomorrow

[roblourens]

And by "it" I mean, I now put that symlink in XDG_RUNTIME_DIR if it is set, so let me know how it goes.

[chriscpritchard]

Hi, just to update it now works.

I'm sorry I was unable to update you with this before!

[connor4312]

Verifying based on followup report