Which SSH private key format should be used with DO 13.6?

Help & Support
1

Hi,

I just got a firewall clearing between my workstation and our Linux Server (Red Hat 9) and I want to connect with SFTP.

But whatever key authentication and format I use, I'm not able to login with Directory Opus 13.6. CMD with "ssh" command works. SFTP itself works with e.g. UltraEdit (but not with all authentications and formats).

I know that you have to completely re-write SSH but I'm wondering how it has worked for the past 15 years for me via a tunnel gateway also via SSH. :wink:

I've also found this in the forum: SSH: How to log in using key files

Info

    ssh -V
    OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2

which generates the new OPENSSH PRIVATE KEY file format by default!

All keys below are created without passphrase.

With ed25519:

    ssh-keygen -t ed25519 -C "test-ed25519" -f "test-ed25519"
    =>
    256 SHA256:ea5YbY2zq1up/AvF048fd5Yz2jeGkHVuoY7iD8xxxxx test-ed25519 (ED25519)
    
    -----BEGIN OPENSSH PRIVATE KEY-----
    Key-Payload
    -----END OPENSSH PRIVATE KEY-----

DO message: "unable to use this key file (openssh ssh2 private key (new format))" and then DO asks for password

With RSA (default 3072 bits) (creates OPENSSH PRIVATE KEY):

    ssh-keygen -t rsa -C "test-rsa" -f "test-rsa"
    =>
    3072 SHA256:znTIR7UHPo+VKX+LPOyE6qGMLpm/mxrt+mC+Lwxxxxx test-rsa (RSA)

    -----BEGIN OPENSSH PRIVATE KEY-----
    Key-Payload
    -----END OPENSSH PRIVATE KEY-----

DO message: "unable to use this key file (openssh ssh2 private key (new format))" and then DO asks for password

With RSA PEM (PKCS1):

    ssh-keygen -m PEM -t rsa -C "test-rsa-pem" -f "test-rsa-pem"
    =>
    3072 SHA256:unqyGE6F28+rGpCuixYY4tgWPZkbv7Bmf9vm5Rxxxxx test-rsa-pem (RSA)
    
    -----BEGIN RSA PRIVATE KEY-----
    Key-Payload
    -----END RSA PRIVATE KEY-----

DO message: "unable to use this key file (openssh ssh2 private key (old PEM format))" and then DO asks for password

With RSA PKCS8:

    ssh-keygen -m PKCS8 -t rsa -C "test-rsa-PKCS8" -f "test-rsa-PKCS8"
    =>
    3072 SHA256:+ek1NrndKQiqQS/A7Komx/A00MUK5cID8JS8ELxxxxx test-rsa-PKCS8 (RSA)
    
    -----BEGIN PRIVATE KEY-----
    Key-Payload
    -----END PRIVATE KEY-----

DO message: "unable to use this key file (openssh ssh2 private key (new format))" and then DO asks for password

I've also tried RSA with RFC4716 and same result with OPENSSH default. I'm not sure if default (OPENSSH format) and RFC4716 are really the same but public key looks like that with "BEGIN OPENSSH PRIVATE KEY".

Also a RSA PEM with 2048 bits which I generated 10 years ago doesn't work on Red Hat 9 AND(!) older 7 server ("old PEM format").

Until yet I'm using a local (Java) service from our company running on my machine which connects to a tunnel gateway server first and then to the final server.

For this I've used the 10 year old RSA PEM with 2048 bits (the public key is saved on the gateway server) and I connect to localhost and a port with 10xxx.

This tunnel still works - will be stopped and replaced by CyberArk soon (another story) - but I don't know why when the key format shouldn't work (readable by DO).

So I've just looked into the LOG file generated by DO 13.6:

    ...
    Reading key file "C:\Users\xxxxx\.ssh\xxxxx@xxxxxxxxxxxxx"
    Unable to use this key file (OpenSSH SSH-2 private key (old PEM format))
    Unable to use key file "C:\Users\xxxxx\.ssh\xxxxx@xxxxxxxxxxxxx" (OpenSSH SSH-2 private key (old PEM format))
    Using username "xxxxx".
    Access granted
    Opening session as main channel
    Opened main channel
    Started a shell/command
    SSH: CTS CONNECTED
    SSH: Listing Directory
    SSH: List complete 26 files.

and wondering that access is granted. :wink:

I've to ask the people responsible for their own Java service program. We have another own "rights management" tool running. I think this service might use this rights management tool behind - regardless of the key. A thing I've never noticed over all the past years.

Final question: Which private key format does currently work with DO 13.6 - because some are to old and the others to new? :wink:

2

You can use PuttyGen to convert the key to the V2 format. See here for details:

We hope to add support for the newer format in the future, as part of replacing the SFTP code in general with an improved version.

3

Hello,

I've the same problem here. I've tried different format with no luck and I'm unable to connect to SFTP with our private OpenSSH key even after conversion. Maybe we are doing something wrong.
Could you help us ? We are testing massively DO actually.

Regards,

Vincent

4

What does the FTP log say the error is?

5

Hello Léo,

Where are stored the log ?

Regards,

Vincent

6

You can open it via the FTP menu (or from the Utility Panel if it's already open).

7

Hello,

Please find the logs :

Ouverture de connexion mycomp1.mydomain.com:22
Server version: SSH-2.0-OpenSSH_7.4
Using SSH protocol version 2
We claim version: SSH-2.0-PuTTY_Directory_Opus
Server supports delayed compression; will try this later
Doing ECDH key exchange with curve Curve25519 and hash SHA-256
Server also has ecdsa-sha2-nistp256/ssh-rsa host keys, but we don't know any of them
Host key fingerprint is:
ssh-ed25519 256 f0:78:88:6b:d6:f4:53:a1:f7:ae:6b:xx:xx:xx:xx:xx
Initialised AES-256 SDCTR client->server encryption
Initialised HMAC-SHA-256 client->server MAC algorithm
Initialised AES-256 SDCTR server->client encryption
Initialised HMAC-SHA-256 server->client MAC algorithm
Reading key file "C:\Users\toto\xxxx\xxxx\id_rsa"
Unable to use this key file (OpenSSH SSH-2 private key (old PEM format))
Unable to use key file "C:\Users\toto\xxxx\xxxx\id_rsa" (OpenSSH SSH-2 private key (old PEM format))
Using username "x".
Disconnected: Unable to authenticate
SSH: Unable to authenticate
Connexion fermée
Ouverture de connexion mycomp2.mydomain.com:22
Server version: SSH-2.0-OpenSSH_8.4p1 Debian-5+deb11u1
Using SSH protocol version 2
We claim version: SSH-2.0-PuTTY_Directory_Opus
Server supports delayed compression; will try this later
Doing ECDH key exchange with curve Curve25519 and hash SHA-256
Server also has ecdsa-sha2-nistp256/ssh-rsa host keys, but we don't know any of them
Host key fingerprint is:
ssh-ed25519 256 68:99:88:d5:33:08:c9:22:65:fe:c7:xx:xx:xx:xx:xx
Initialised AES-256 SDCTR client->server encryption
Initialised HMAC-SHA-256 client->server MAC algorithm
Initialised AES-256 SDCTR server->client encryption
Initialised HMAC-SHA-256 server->client MAC algorithm
Reading key file "C:\Users\toto\xxxx\xxx\id_rsa"
Unable to use this key file (OpenSSH SSH-2 private key (old PEM format))
Unable to use key file "C:\Users\toto\xxxx\xxx\id_rsa" (OpenSSH SSH-2 private key (old PEM format))
Using username "x".
Disconnected: No supported authentication methods available (server sent: publickey,keyboard-interactive)
SSH: Fatal: Disconnected: No supported authentication methods available (server sent: publickey,keyboard-interactive)
Connexion fermée

Regards,

Vincent

8

Hello,

I'm still stuck with the problem which mostly can be a "PEBKAC".
I'd like to know if it's possible to make ssh tunnel with Dopus ?

Regards,

Vincent

9

Unable to use this key file (OpenSSH SSH-2 private key (old PEM format))

That means the format isn't one Opus supports. You should be able to convert it using PuttyGen:

If you still see a (different) error about authentication after converting the key, it might mean the server doesn't allow the encryption algorithms Opus supports. We're currently working on replacing the SFTP code with a new library which will handle that. (We also hope to add support for more key types when we do that, or soon after, so you don't have to convert them between formats.)

10

Hi,

create ".ssh" directory if it doesn't exist:

mkdir %USERPROFILE%\.ssh
cd /D %USERPROFILE%\.ssh

Create ED25519 key (is new default by OpenSSH):

ssh-keygen -t ed25519 -f "userid_AT_target.server"

Convert the private key to PPK format with "winscp":

cd /D C:\Program Files (x86)\WinSCP
winscp.com /keygen "userid_AT_target.server" "/output=userid_AT_target.server.ppk"

I've used "winscp" because I've found this (old) command line call by the winscp developer somewhere.

Note: I've used winscp 5.11.3 from 2017-12-14 (installed on our company PC) which creates the PPK2 format by default (which DO currently requires!).

It might have changed with the latest release 6 and might create PPK3 file format by default. Please check the command options and adapt the call maybe. I didn't check until yet.

Use the PPK file as private key file in DO SSH connection settings.

This must work. It does work for me (to connect to a Red Hat 9 server).

Of course you can try Putty to convert. I haven't installed nor tried it. I only use the new Windows Terminal for SSH sessions anymore.

I hope this helps.

11

@Leo :
I had tried to convert my key to v2 with a recent PuttyGen and I had an error that said that DOpus was unable to use new PEM format.
@fuzi1968
Conversion is working with this old version of winSCP !

Thank you to all of you for your help and patience, now it's working for me. No need tunnel anymore :smiley:

Just a last thing : I need to quit DOpus in order to use the converted key, otherwise, even if setup pointed to it, old key is still used. Weird.

Regards,

Vincent

12

Hello,

Just registered to Dopus 13.
It make a while since I bought Magellan and I'm happy to come back.

Regards,

Vincent

13

Hi, I've also been having strange problems here. I've created a ppk v2 file, that I have verified works with identical settings for a standard ssh client, putty and WinScp. However, the server reported pubkey refused.

After some debugging I noticed that dopus was trying to use ssh-rsa as a pubkey signature algorithm, which has been disabled by default for about 4 years.

The fix on the serverside is then to put
PubkeyAcceptedAlgorithms +ssh-rsa
in /etc/ssh/sshd_config.

Is there a way to change this in dopus? I have not found one.

I've seen in another thread that the goal is to fully replace the sftp code – hoping you get around to this soon, as this behavior will definitely cause confusion and time lost to unnecessary debugging. @Leo

14

Hi @bsm,

please see my reply from "Aug 8 2024" and follow they key creation instructions.

ED25519 works with DO 13 in the PPK v2 file format. Try to download and install winscp with the version 5.11.3 as recommended in my reply and convert the key to PPK v2.

However, wondering that RSA is currently disabled by default on any server. On our new Red Hat 9 it isn't.

I hope this helps.

1 Like
15

@Leo

When you re-write SSH please keep in mind that we are using "Cyberark" as solution and 2FA with mobile phones is used when we connect to our servers.

For every connection which is built I have to confirm on my company mobile phone.

When I'm connected with DO (sftp) and switch around (path) or transfer a file or something like that, most of the time I have to confirm multiple times (and get confused) because DO connects multiple times to the server. This must not happen in the future!

When you re-write SSH/SFTP please contact me for Beta-Testing DO in our company with Cyberark (if you can't).

Thanks a lot

Update: We in our company don't connect directly to the destination server (test and production) anymore. We use an internal server with Cyberark and this forwards to the final destination server. The connection in this case to Cyberark server happens with user+password but on the destination server there is a SSH (generated by Cyberark server (rsa 2048)). To our development server I connect directly with SSH.

Update2: When I connect to the test or production server, it works like this:

ssh user1@user2@destinationserver2@destinationserver1

where user+server1 is the Cyberark server and server2 the real destination server.

To my development server directly:

ssh user2@destinationserver2

The SSH key definition is in my config file in the .ssh directory within my user directory (/home/myuser/.ssh/config). Would be nice if DO or the underlying libraries would also support the config file from SSH command line.

16

As soon as it's ready for testing, it will be part of the public betas and there for everyone to test.

Apologies for the delay in having it ready. Family health issues have gotten in the way lately, but are hopefully settling down now.

1 Like
17

Rh9 seems to distribute openssh in version 8.7p1 [2021-08-20].

ssh-rsa when used with sha-1 has been disabled by default since openssh8.8 because of security concerns (see https://www.openssh.com/txt/release-8.8). My understanding is, that since the actual signature algorithm used by ssh-rsa during authentication still uses SHA-1 internally, the ssh authentication fails. This seems to a common source of confusion.

For now I have just reenabled ssh-rsa, since it is not a big concern currently, but I may try your fix in the future. Thanks!

18

@bsm:

Yes, when i run "ssh -V" I currently get "OpenSSH_8.7p1, OpenSSL 3.2.2 (4 Jun 2024)" (incl. all the patches from our admins).

But I use ED25519 everywhere now (ssh, jenkins, git/bitbucket etc.) - no RSA1 or RSA2 anymore.

ssh-keygen -t ed25519 -C "userid_AT_target.server" -f "userid_AT_target.server"

This generates the key in the new OPENSSH file format (default for ED25519).

Not sure, but I think OpenSSH new default file format is now OPENSSH in the private key file also when creating a RSA2 key which exactly starts with:

-----BEGIN OPENSSH PRIVATE KEY-----

All other text (header) is the old PEM format. Not sure but I think this also confused DO and that's why it tries with RSA1?. Can't remember exactly anymore.

-----BEGIN PRIVATE KEY----- ... PKCS#8
-----BEGIN RSA PRIVATE KEY----- ... PKCS#1

So when you generate a RSA key then you maybe still have to add the option to create the PEM format (maybe):

ssh-keygen -m PEM -t rsa -b 4096 -C "blabla" -f "blabla"

With

ssh-keygen -l -f "blabla"

you can get information about the key type of a file.