4

I have one windows service which will use plink.exe for SSH connection and I found that Plink cannot find the running Pageant.

Here is the steps I have done so far.

  1. Install Windows service to run as particular user
  2. Before starting Windows service, I log in as that user and start Pageant with PuTTY generated key.
  3. Then I start the Windows service (but I can't manage to make it work since Plink cannot find Pageant and server reply as No supported authentication methods available.)

Note: If I run Windows service as console application with that user, everything is working fine.

Martin Prikryl
  • 188,800
  • 56
  • 490
  • 992
Soe Moe
  • 3,428
  • 1
  • 23
  • 32

3 Answers3

4

PLink will be run in Service session (Session\0) while pageant runs in user session (Session\1). Plink uses some interprocess communication which, as it looks from your problem, doesn't work across sessions. Most likely there's MMF communication inside and objects are created without prefix, i.e. they become session-only (not global). You would need to build custom version of plink to solve the problem.

Eugene Mayevski 'Callback
  • 45,135
  • 8
  • 71
  • 121
  • It's not that Pageant does not allow to talk to applications running in a different session by mistake. It's deliberate security restriction. See [my answer](http://stackoverflow.com/a/27776179/850848) for details. – Martin Prikryl Jan 05 '15 at 09:03
3

Pageant explicitly allows feeding keys to an application (PuTTY, PSFTP, PSCP, WinSCP, FileZilla) running in the same Windows session only. This is obviously for security reasons, not to allow a different user on the same machine hijack private keys loaded by another users. And even for convenience (ironically), so that you do not inadvertently use keys of a different user (leading possibly to having your account locked due to invalid login attempts).

Also note that the Pageant is not intended for an automation anyway. For the automation, use the private key explicitly, using the -i command-line parameter.
See https://the.earth.li/~sgtatham/putty/latest/htmldoc/Chapter3.html#using-cmdline-identity

Such private key have to be unencrypted. Note that this imposes security risk, if someone gains access to the key. You should consider restricting an access to the unprotected private key file to the local account that runs the script only (using Windows file system permissions).

Martin Prikryl
  • 188,800
  • 56
  • 490
  • 992
2

As @Eugene point out, it is Session 0 Isolation.

I managed to solve the issue by not using agent but directly passed the private key and password to plink.exe. By doing that, I'm able to run without using pageant.

To start plink.exe without agent;

plink.exe -noagent -i private_key.ppk -pw mypassword -P 1234 user@host.com
Community
  • 1
  • 1
Soe Moe
  • 3,428
  • 1
  • 23
  • 32
  • 1
    Kind of destroys the whole idea of keeping the key passphrase a secret. – Zan Lynx Sep 12 '12 at 21:41
  • @ZanLynx yeah. agreed, but I am too dumb to find another way to solve this issue. :( Please share with us if there is better solution so that not only me but others also can get benefit from it. Thx. :) – Soe Moe Sep 18 '12 at 14:00
  • [You could encrypt a file with EFS](http://mbrownnyc.wordpress.com/2012/09/21/efs-encryption-the-messy-side-of-file-encryption/), then run the service as the user who has the EFS keys in their store... but I'm having a lot of trouble with pipes and the cmd.exe host and services. More than likely this can be solved by creating the service using the old service tool srvany.exe (note that it is part of the 2003 resource kit). But if that doesn't work, you need a different process host. – brandeded Oct 01 '12 at 16:03
  • 1
    If does not make any sense to combine `-i` with `-pw`. The `-pw` is for providing an account password, not a private key passphrase. – Martin Prikryl Jan 05 '15 at 09:01
  • Maybe it's not session 0 isolation: I've got a box still running WinXP, and according to the MS docs you linked to, everything runs in session 0 on WinXP -- but after SSHing in (it runs Bitvise SSH server), `plink` refuses to find the already-loaded-into-Pageant key. Running `tasklist` confirmed that both `PAGEANT.EXE` and its own process (started from inside the ssh session) were in session 0. Hmm... – j_random_hacker Oct 28 '15 at 15:44
  • OTOH, SSHing in and starting a scheduled task that ran `plink` *did* work... So I think some kind of context *is* important, but perhaps not the session ID. – j_random_hacker Oct 28 '15 at 15:54