Relax implicit ASKPASS requirements on Windows in X11 forwarding scenarios#428
Conversation
|
@bagajjal Can I get an assist here? These test failures seem unrelated to my changes. The tests pass locally too. |
|
Ping? Would be a real shame if this didn't make it into Windows vNext. |
|
@riverar - We are seeing random failures specific to proxycommand. I have disabled them for now. Please sync again and do a push with minor change (adding a space in a file) so the AppVeyor build will start again. Do you know what is the default askpass (_PATH_SSH_ASKPASS_DEFAULT) used in Ubuntu? They don't have "/usr/X11R6/bin/ssh-askpass" on Ubuntu. |
riverar
force-pushed
the
change/relax-askpass-x11
branch
from
48919b4 to
911105a
Compare
|
@bagajjal Thanks, triggered a new build. I pulled down the sources for openssh on Ubuntu Bionic and it has Installing ssh-askpass results in: Going to assume |
| else | ||
| askpass = _PATH_SSH_ASKPASS_DEFAULT; | ||
|
|
||
| #ifdef WINDOWS |
There was a problem hiding this comment.
DISPLAY environment isn't applicable for windows?
Change the logic to have line 188 to197 for windows.
Disable and don't touch the existing code for windows.
This makes the users not to worry about additional DISPLAY environment variable which is not applicable for windows.
There was a problem hiding this comment.
DISPLAY use is required on the source side for X11 forwarding to work. It points to an X Display Server of the user's choosing (e.g. DISPLAY=localhost:0.0). XMing is a popular X Display Server that runs on Windows.
Basically, ssh connects to the configured X Display Server and tunnels traffic to/from the target. sshd on the target side will automatically set up DISPLAY for application use.
So the commit only introduces one change: On Windows, it stops forcing the user to use ASKPASS if SSH_ASKPASS is not defined. If it is, business as usual. No impact to non-Windows platforms.
Am I missing something?
There was a problem hiding this comment.
I am not familiar with the x11 forwarding. Could you please share the steps on both the client and server so I can test?
There was a problem hiding this comment.
Absolutely, happy to share. It's way easier than it sounds too.
Try this:
- On Windows, install XMing
- Chose to display programs in
Multiple windowsand keep the Display Number at-1. - Keep all other defaults
- Chose to display programs in
- Start the display server, if not already running (
XLaunchin Start). This will install an icon in your notification area (tray). - In a PowerShell window, issue the following commands (replacing text as needed):
$env:DISPLAY="localhost:0.0" ssh -Y user@host - On the target (assumed Linux with working package manager), install
xorg-x11-appspackage. - On the target, start
xclockand observe window appears on Windows desktop!
There was a problem hiding this comment.
Thanks. It worked.
I was puzzled how the request is forwarded to xming server when we use ssh -Y user@host.
ssh client logs shows there is no xauth program but still we are able to forward the X data to xming.
debug1: No xauth program.
Warning: No xauth data; using fake authentication data for X11 forwarding.
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 1
There was a problem hiding this comment.
Great, so now to reproduce the issue this PR fixes:
- Ensure
C:\dev\ttydoesn't exist - Ensure
DISPLAYis set, thenssh -Y user@host - Observe authentication failure
The failure is a result of ssh passing the check at line 181 (use_askpass is 1 because we don't have a tty), then entering a block of code that assumes ASKPASS is present, which fails.
There was a problem hiding this comment.
I got the need for the fix.
I didn't understand how the data is forwarded as we didn't specify the xauth program when we do ssh -Y user@host.
debug1: No xauth program.
Warning: No xauth data; using fake authentication data for X11 forwarding.
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 1
Also one observation, GUI doesn't display colors on windows side.
There was a problem hiding this comment.
Should see colors, try xclock -bg pink.
2 participants
For historical reasons, if environment variable
DISPLAYexists,read_passphrasewill force users down a path that requires use of an askpass implementation specified viaSSH_ASKPASS(or internal defaults). On Windows, where askpass generally won't exist, this will result in complete login failure.There is on-going discussion--18 years and going--about refactoring
read_passphraseto eliminate this behavior and introduce controls to give users explicit control overSSH_ASKPASSbehavior.The following constraints were assumed:
SSH_ASKPASSusers on Windows(fixes PowerShell/Win32-OpenSSH#1515)