cuviper / ssh-pageant

An SSH authentication agent for Cygwin/MSYS to PuTTY's Pageant.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Pageant key not available under MinTTY

dewarrn1 opened this issue · comments

I'm going to apologize in advance for not having a better sense of what my specific problem is, but after happily using ssh-pageant for a couple of years, a recent Cygwin update has broken something, and I can't identify the cause. Briefly, keys loaded through Pageant are no longer available under MinTTY, but work fine in Windows (through Putty, etc.). Some accompanying oddities:

  • Although ssh-pageant is still called from my .bashrc file, the $SSH_AUTH_SOCK and $SSH_PAGEANT_PID environment variables are no longer assigned when opening MinTTY.
  • Calling "eval $( ssh-pageant -q )" at the command line does assign those variables, but ssh sessions opened afterward return "Permission denied (publickey)", suggesting that Pageant's key files are still not available.

I've reinstalled Cygwin (now on 1.7.9), updated Pageant (v0.62), and am using ssh-pageant v1.1. Any help would be greatly appreciated, and if there are any tests that I can run to help with the diagnosis, I'd be happy to try them. Thanks!

I also use MinTTY, and have never had any issue. I haven't updated Cygwin in a while though. Just for fun, can you try with ssh-pageant 1.0 too? I made authentication changes in 1.1 that could conceivable cause issues. (That's in relation to issue #13.)

You can test with "ssh-add -l" to simply see what keys are detected. You can further try "ssh-pageant ssh-add -l" to nest the processes directly, so the shell environment won't matter.

It's going be a few days before I can test this thoroughly myself, but let me know what you find.

Thanks for getting back so quickly! I was able to test a few things, and the behavior of ssh-pageant 1.0 and 1.1 appear to be identical in the cases mentioned below. Here's the system output for your suggestions:

$ ssh-add -l
Could not open a connection to your authentication agent.

$ ssh-pageant ssh-add -l
2048 etc:etc:etc:etc:...:etc /path/to/my/key/.ssh/keyname (RSA)

Basically, the nested case reports the key I've got loaded into pageant, so maybe it's a shell thing? I'll keep poking around in the meantime.

Solved! Adding the -s option to the .bashrc invocation of ssh-pageant fixed everything. Why this changed from one moment to the next (it worked fine for at least 18 months before a few days ago) is unclear, but I'm glad it was an easy fix. Sorry to bother, many thanks!

Aha! In the absence of -c or -s, ssh-pageant tries to guess based on the SHELL environment. If that is set and contains any variant of "csh", then it implies -c, otherwise -s. It'd be nice to know why $SHELL is apparently not correct for you though.

Closing. If you determine that your $SHELL is actually correct, but the autodetection still isn't right, then feel free reopen with those details.