Error while signing data with privateKey: error:06000066:public key routines:OPENSSL_internal:DECODE_ERROR

[miguelbonim]

Issue Type: Bug

Error while signing data with privateKey: error:06000066:public key routines:OPENSSL_internal:DECODE_ERROR

Extension version: 1.12.7
VS Code version: Code 1.36.0 (0f3794b38477eea13fb47fbe15a42798e6129338, 2019-07-03T13:25:46.372Z)
OS version: Windows_NT x64 10.0.17763

System Info

Item	Value
CPUs	Intel(R) Core(TM) i5-7300HQ CPU @ 2.50GHz (4 x 2496)
GPU Status	2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on native_gpu_memory_buffers: disabled_software oop_rasterization: disabled_off protected_video_decode: enabled rasterization: enabled skia_deferred_display_list: disabled_off skia_renderer: disabled_off surface_synchronization: enabled_on video_decode: enabled viz_display_compositor: disabled_off webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	23.87GB (18.35GB free)
Process Argv
Screen Reader	no
VM	50%

[miguelbonim]

I just solved this bug.
Just go back vscode to version 1.34.0
https://code.visualstudio.com/updates/v1_34

[ptitbic]

well... getting back to a previous version (1.35 works fine as well) is not a solution !
the extention is not working anymore with vscode 1.36 :-(

[RattyBiscuit]

well... getting back to a previous version (1.35 works fine as well) is not a solution !
the extention is not working anymore with vscode 1.36 :-(

I agree - this is not a solution :-)

[dylanh724]

That is a workaround - not a solution. Can also confirm it's down completely! The priority level of this critical issue should be bumped.

[KingAserd]

Same problem here with windows 10. Exported the .pem file to OpenSSH key with PuTTY Key Generator and it seems to work again.

[ptitbic]

Good catch @KingAserd, with another key format this is working...
Bug still there, but working workaround for the last version then.

[sventertainment]

Got the same problem with macOS. Any suggestions on that?

The key is working when using the ssh command or the ForkLift sftp App.

[cnrpman]

Got the same problem with macOS. Any suggestions on that?

The key is working when using the ssh command or the ForkLift sftp App.

Convert the private key back to PEM to solve that
https://serverfault.com/a/950686/531628

[inteist]

Why was this closed? I am still experiencing the issue. And "convert to PEM" is not really a solution.

[alexfornuto]

I agree with @inteist, this issue isn't documented and PEM format isn't what's created by ssh-keygen by default. Switching they key format could have unintended consequences for other systems using the same key.

[feakuru]

Pinging for a reopen here, suffering on MacOS from this

[gus3inov]

It seems that this issue should be open to find a great solution, converting PK to PEM breaks backward compatibility with other services where PK is already registered

[karamjot-singh]

Convert .ppk to .pem using PuttyGen.
Then use it in your sftp config file and it will work!!!

[alexfornuto]

Convert .ppk to .pem using PuttyGen.
Then use it in your sftp config file and it will work!!!

This much has already been discussed. I think that the issue now is that having to convert to PEM is undesired.

Consider non-Windows users, for whom a key pair is S.O.P. and expected in that format by other tools. Making a PEM export specifically for this plugin is less than ideal.

[Spongman]

broken on linux.

[alexfornuto]

broken on linux.

Not super useful input. It's "broken" until you convert to PEM, which is the whole point of this thread.

@liximomo Do we need to make a new issue to get some love on this, or can you re-open it for us? OP closed it because he "solved" by rolling back versions.

[inteist]

converting to pem format is not an adequate solution.

Moreover it did not solve it for me. I wonder whether I did something wrong or it just doesn't work on OS X ?

[alexfornuto]

converting to pem format is not an adequate solution.

I think we're all in agreement on that.

Moreover it did not solve it for me. I wonder whether I did something wrong or it just doesn't work on OS X ?

Not enough information here for me to help you debug. But we shouldn't have to, the author should be responding to this.

[inteist]

@alexfornuto, unfortunately, it looks like this plugin is dead.
There was no response from the author on this issue since September and I just looked up other (new and open) issues and there is no response from the author as well for several months.

[case90]

Convert .ppk to .pem using PuttyGen.
Then use it in your sftp config file and it will work!!!

Great !! this works for me in version 1.43

[Timmmm]

I think this is almost certainly a bug in BoringSSL. Basically Node's crypto.sign() triggers this bug but only when you run it from an Electron Renderer process (i.e. Chromium), because Chromium uses BoringSSL. Node itself uses OpenSSL which doesn't have this issue.

This means the solution is not easy - the best thing would be for Google to fix BoringSSL, but this is Google we're talking about so let's not hold our breaths. The only other workaround I can think of is to move the SSH code from the Renderer process to the Main process, but I don't know how feasible that is for this project.

For users the best workaround is to convert the key itself.

[novayadi85]

Convert .ppk to .pem using PuttyGen.
Then use it in your sftp config file and it will work!!!

This works for me..
I convert my ppk with this guide.
https://medium.com/@Faizan/converting-ppk-to-pem-files-on-macos-da1af60a5f1d

[Timmmm]

By the way it turned out it wasn't a bug in BoringSSL - BoringSSL is just more strict about rejecting invalid keys. The real culprit was the ssh2 library which this extension also uses. ssh2 currently encodes invalid keys when they contain integers that start with 9 (so you will only see this bug randomly on some keys). I made a pull request to fix it: mscdex/ssh2-streams#164

[dylanh724]

@Timmmm I branched off and pulled your changes -- how do I build it to make it work with vscode as a replacement extension?

[dylanh724]

Got it (Long-Term Workaround):

Thanks to @Timmmm:

1. Download ssh2-streams-0.4.10-pemPatched.zip below using Tim's fix patched in.
2. Go in top dir, then extract contents to %userprofile%\.vscode\extensions\liximomo.sftp-1.12.9\
3. Restart vscode
   ssh2-streams-0.4.10-pemPatched.zip

Alternately

You could probably just update the node_module ssh2-streams - I heard they fixed it themselves.

@liximomo : This is not a fix

All the dev has to do is rebuild with the updated ssh2-streams node module to fix this bug.

This is merely a workaround. Any updates from liximomo will break this workaround. That is, if that dev didn't abandon the project... (it's been 14mo)

[wisdomQiuqiu]

I've already downloaded “ssh2-streams-0.4.10-pemPatched.zip” And restart vscode
There are still the following errors

[11-02 14:56:26] [error] Error: Failure
at SFTPStream._transform (/Users/yuyanqiu/.vscode/extensions/liximomo.sftp-1.12.9/node_modules/ssh2-streams/lib/sftp.js:412:27)
at SFTPStream.Transform._read (_stream_transform.js:189:10)
at SFTPStream._read (/Users/yuyanqiu/.vscode/extensions/liximomo.sftp-1.12.9/node_modules/ssh2-streams/lib/sftp.js:183:15)
at SFTPStream.Transform._write (_stream_transform.js:177:12)
at doWrite (_stream_writable.js:418:12)
at writeOrBuffer (_stream_writable.js:402:5)
at SFTPStream.Writable.write (_stream_writable.js:302:11)
at Channel.ondata (_stream_readable.js:720:22)
at Channel.emit (events.js:203:13)
at Channel.EventEmitter.emit (domain.js:476:20)
at addChunk (_stream_readable.js:295:12)
at readableAddChunk (_stream_readable.js:276:11)
at Channel.Readable.push (_stream_readable.js:210:10)
at SSH2Stream. (/Users/yuyanqiu/.vscode/extensions/liximomo.sftp-1.12.9/node_modules/ssh2/lib/Channel.js:167:15)
at SSH2Stream.emit (events.js:203:13)
at SSH2Stream.EventEmitter.emit (domain.js:476:20)
at parsePacket (/.vscode/extensions/liximomo.sftp-1.12.9/node_modules/ssh2-streams/lib/ssh.js:3288:10)
at SSH2Stream._transform (/.vscode/extensions/liximomo.sftp-1.12.9/node_modules/ssh2-streams/lib/ssh.js:694:13)
at SSH2Stream.Transform._read (_stream_transform.js:189:10)
at SSH2Stream._read (/Users/yuyanqiu/.vscode/extensions/liximomo.sftp-1.12.9/node_modules/ssh2-streams/lib/ssh.js:253:15)
at SSH2Stream.Transform._write (_stream_transform.js:177:12)
at doWrite (_stream_writable.js:418:12)
at writeOrBuffer (_stream_writable.js:402:5)
at SSH2Stream.Writable.write (_stream_writable.js:302:11)
at Socket.ondata (_stream_readable.js:720:22)
at Socket.emit (events.js:203:13)
at Socket.EventEmitter.emit (domain.js:476:20)
at addChunk (_stream_readable.js:295:12)
at readableAddChunk (_stream_readable.js:276:11)
at Socket.Readable.push (_stream_readable.js:210:10)
at TCP.onStreamRead (internal/stream_base_commons.js:166:17)

[XALM1337X]

This is still an issue. VSCode version 1.54.2

[jorgedjn58]

This bug is not fixed yet, still an issue in:

Version: 1.56.2
Node.js: 14.16.0
OS: Windows_NT x64 10.0.19042

Even with .ppm key files. I´m getting the following error when trying to upload file:

[05-28 00:59:27] [debug] Local ident: 'SSH-2.0-ssh2js0.4.5'
[05-28 00:59:27] [debug] Client: Trying 192.168.130.104 on port 22 ...
[05-28 00:59:27] [debug] Client: Connected
[05-28 00:59:27] [debug] Remote ident: 'SSH-2.0-OpenSSH_7.4'
[05-28 00:59:27] [debug] Outgoing: Writing KEXINIT
[05-28 00:59:28] [debug] DEBUG: Comparing KEXINITs ...
[05-28 00:59:28] [debug] (local) KEX algorithms: ecdh-sha2-nistp256,ecdh-sha2-nistp384,
Removing Logs To avoid Huge output*************
[05-28 00:59:28] [error] Error: [192.168.130.104]: Error while signing data with privateKey: error:06000066:public key routines:OPENSSL_internal:DECODE_ERROR.

I´m using a simple sftp config as follows:

{
"name": "GD",
"host": "192.168.130.104",
"protocol": "sftp",
"port": 22,
"username": "jorge",
"privateKeyPath": "/Users/jorge/.ssh/privkeycentosdev.pem",
"passphrase": "*************",
"remotePath": "/home/jorge/scripts",
"uploadOnSave": false
}

The same key works just find from another app like MobaXterm to the same local server, as shown below:

FromMobaXterm:
Using private key authentication...
Connection to 192.168.130.104... Please wait.
Connected to 192.168.130.104.
Starting SSH authentication...
Trying SSH authentication GSSAPI_WITH_MIC...
SSH GSSAPI_WITH_MIC authentication failed.
Trying SSH authentication PUBLICKEY...
Trying SSH authentication PUBLICKEY...
SSH authentication success!
SFTP connection started.
SSH server name: OpenSSH_7.4
SFTP session started!
Opening directory /home/jorge...
Open directory command received
Directory content listed

Is this SFTP extension working fine for any windows user?

[Timmmm]

Yeah just to clarify this bug won't be fixed because the error is in the SSH library that this extension uses and the PR that fixes the bug isn't being merged. It isn't being merged because the original author is rewriting the library.

It would have been nice if they could have just merged the fix since it's so trivial, but on the plus side they do at least appear to be making progress on their rewrite.

So the options for VSCode-SFTP are:

1. For the current ssh2 library and incorporate the fix (I would do that to be honest).
2. Wait for mscdec's rewrite.

There's no need to keep saying "this is still an issue" and posting logs anyway.

[lhdamiani]

Found a solution that worked for me here

basically, it worked out of the batch once the OpenSSH private key was converted to PEM format.