OpenSSH session support for PKI

[cadayton]

For an OpenSSH session how does one reference the appropriate PKI key. I'm not seeing any place to enter the PKI key for an OpenSSH session.

[cadayton]

I stumbled upon were to specify the private PKI key. I really don't want to do this 537 times for each login.

Might there be a master Json or XML config file that could be batch updated?

[kingToolbox]

Wow, I never thought I needed to be responsible to openssl ssh_config. You are using a brand new ssh client, and each tool has its own unique design and configuration format, and I bet that almost no ssh client can meet your migration requirements. 😄

But don't worry, as long as it is a problem, there will always be a solution.

It is true that all the sessions is in the file WindTerm-Install-Path/profiles/default.v10/terminal/user.sessions, and the format is json, which is designed to facilitate scripts to read or generate large quantities of sessions. However, for security reasons, all login information is encrypted and stored, including user name, password, PKI keys and so on, so write PKI key into it via script is not feasible.

If you really want to do this, you can read Cryptographic.cpp. If the script is strictly written according to the encryption algorithm, it is indeed feasible, but it is more cumbersome. and takes more time than you fill in pki keys manually.

So I suggest that because WindTerm supports agent forwarding, the easiest way is to use Pageant, just download it and then load pki keys into it, everything will be ok.

[kingToolbox]

By the way, I will explain why pki keys are not imported automatically, because the user’s master password is required for the encrypted storage of login information, and the master password is only set when the user opens the session for the first time, so when the ssh pki keys are imported, there is no master password, so they cannot be imported.

When the installation package is available in the future, the user will be required to set the master password during the installation process, and then the ssh_config can be completely imported.

[cadayton]

I'm using the Windows OpenSSH client. In the folder .ssh, the file 'config' contains the ssh entries. I see WindTerm is reading this file and picking up the host entries given the names WindTerm is populating in the Session Pane. When I open a OpenSSH session from the pane, it prompts for account and password. The config entry has an account name and IdentityFile attributes specified, I was just expecting WindTerm to pickup those attribute values is all and not prompt me for that information.

[kingToolbox]

As I explained above, only Host, HostName and Port has been imported.

I think the path of the private key file and the user name are very important information that needs to be protected, so unlike openssl, these are all encrypted and stored.

May I ask a important question, you have 537 sessions now. Is their login username and PKI key is all same or is different? If they are share the same or several user name and PKI key, there is still a chance to solve this problem simply.

[cadayton]

Yes, all the OpenSSH sessions are using the same account and IdentityFile attributes. PuTTy sessions are using a different private key file but same account.

OpenSSH on Windows requires that the folder .ssh be locked down to only the account owning the folder otherwise ssh client won't work.

[kingToolbox]

This is very good news. Maybe we can solve the problem relatively easily.

• First, choose session 537 to log in with user name and public key. When logging in, please check "Auto Login next time".
• After logging in successfully, open WindTerm-Install-Path/profiles/default.v10/terminal/user.sessions with an editor and goto the session 537's configuration.
• You will see "session.autoLogin" now, copy this line to the configuration of all sessions with the same user name and PKI key.
• Done.

You can repeat this method for putty sessions. I really hope this method works.

[kingToolbox]

Hi, is your problem solved?

[cadayton]

No. For some reason PKI login isn't successful. PKI file doesn't have a password. The OpenSSH CLI command is working with the same info though. So not sure what I'm doing wrong.

PS> ssh username@somewhere.org -i pathtoPrivatePKI

[kingToolbox]

I will confirm whether there is a problem with the public-key login code. Although it has been tested in detail before, but the Linux version made many new changes.

If there is a problem, I will fix it in the new v1.9.2, which will be released today. Please try again later.

[kingToolbox]

The new version 1.9.2 has been released. You can try the new version. But I confirmed that the previous versions have no problems with public-key log in, whether it has or does not has a password. I can log in successfully in multiple systems.

You can simply test by using ssh-keygen to regenerate a pair of keys to see if you can log in with WindTerm successfully. The default RSA format will be ok.

[cadayton]

OpenSSH PKI method is now working with 1.92. I didn't need to regenerate a key pair.

Unfortunately, PKI access via PuTTy is having the same issue that OpenSSH PKI method did previously. PuTTY sessions using the account/pw combination is working.

[kingToolbox]

WindTerm dose not support PuTTy's PPK format. You need to convert them to the OpenSSH format.(convert-ssh-key-to-ppk, convert-ppk-to-ssh-key)

If it is not convenient to convert, I recommend using Pageant. You just open Pageant and load private keys, WindTerm will do the rest.

After you log in successfully, have you tried to copy "session.autoLogin" to other sessions? Does it work?

[kingToolbox]

Hi, I added the independ IndentityFile in WindTerm configuration and the ability to automatically import the IndentityFile field from OpenSSH configuration in the new version 2.0.0_prerelease_3. You can download and check. I think you can easily import your 537 OpenSSH sessions now. 😄

[kingToolbox]

The feature request has been implemented in the new v2.0.0. This issue will be closed and welcome to continue submitting new issues and feature requests, thank you.