Hi,
Have used the trial on recommendation of a friend who's a paying customer and it seems great and do what I want (and what he's wanted for awhile).

The issue is that I have moved all my ssh auth over to a yubikey, but logview doesnt seem to support the 2 ways I can currently auth to my servers.

Could a pageant style authentication method be added? (so no need for cert, password, etc) as this is handled in the background. This works fine with putty, winscp, filezilla pro etc

OR

I also have setup a ed25519-sk key (ecdsa-sk is also supported by later versions of OpenSSH), but you only seem to support the PPK format, which you cant seem to currently convert ecdsa-sk/ed25519-sk OpenSSH to PPK format. So the question is could  OpenSSH key formats (including ecdsa-sk/ed25519-sk) be supported directly?

I think the pageant method is probably best - this way any future changes to keys/dongles/etc are supported by the agent and dont require updating your app.

This is currently a deal breaker for me and also causing the friend who recommended me issues as hes in the process of moving to a yubikey too.

Thanks!

Hi Slack,

Thanks for the feedback.

Pageant is not currently supported.  This is something we will look at in a future release.

However, we do support ed25519.  We introduced this in v2.5.14 as a plugin, but the latest version of LogViewPlus supports ed25519 without requiring a plugin.  Please see the latest BETA version.  

Hope that helps,

Toby

Hi,

Glad to hear pageant might/is/will be coming!

ed25519 support isnt ed25519-sk support. ed25519-sk generates a key that mostly lives on a FIDO2 security token, the file on the PC is just a stub of sorts that points to the security token.

Thanks for the clarification.

I am afraid I do not have a good solution.  Our networking library is largely provided by a third party (Rebex) and it seems they do not yet support Pageant or ed25519-sk.

We monitor Rebex closely and I will keep an eye out for changes.  I know that Pageant is planned, but I am not sure when this will be available.

Hope that helps,

Toby

OK, thanks for your response. Appreciate hands are tied as waiting on upstream library. I will keep checking back.

Thanks!

Thanks for your understanding Slack.  Please let me know if you have any further questions or issues.

Toby

Hi again,

So I have worked around this issue as follows:
putty has support for authenticating via gpg-agent, so I connect to the server that is pubkey only auth remotely and set up a tunnel:
9229 -> 127.0.0.1:9229
I allow password auth on the server on 127.0.0.1 only:
sshd_config -
Match Address 127.0.0.1
  PasswordAuthentication yes

I can then connect logview to the server on 127.0.0.1:9229 and it all works fine.

Is there a plugin or the ability to add a command to run BEFORE connecting? I could call putty before attempting to access the remote fillesystem with "putty.exe - load "profile name here". If logview could run a command before connecting, this would work around the auth issue without needing upstream support for pageant etc.

Thanks!

Glad to hear you got it working Slack - thanks for sharing!

Running a command before connecting is currently not supported.  However, LogViewPlus does support External Commands.  This might help if you wanted to run a command before connecting, but this would still need to be a manual action.  Open Actions would not work in this case as they are executed after the file is initially downloaded.

Executing a command before connecting is tricky as re-connections happen frequently.  Also, there may be multiple files open from the same server. 

I think what we might need to do here is add a configuration option to Open Actions which allows the user to specify if the command should be executed before or after the file is downloaded.  I will add this to our feature request list.

Hope that helps,

Toby

I would probably not run the putty command directly, I would probably craft a batch file that will launch putty and confirm connectivity to the server (and reconnect if required). So that would all be handled externally, so far as logview is concerned - its no different to any other network/remote share.

If logview executed the command/batch on all reconnect attempts (rather than just initial connection) I could add some logic around that too.

All that would be needed would be logview to launch the command and await a successful return code, the rest could be handled externally via the ran command.

My preference would be to execute the command once before the initial connection on a per-file basis.  Spawning a new process for every connection attempt would only need to happen once to annoy a user - especially if those processes were expensive.  I also don't want to add something that the user then needs to 'work around'.  

Also, note that LogViewPlus can wait for a program to exit, but it does not check the return code status.