phpseclib: unable to read key error in PublicKeyLoader - phpseclib v3.0.12

So one interesting thing about encrypted OpenSSH keys is that node.js can do them super fast:

https://gist.githubusercontent.com/haythemhammami/83e60a81d6066b5652bc57876947c7a3/raw/b4da272983a63687b8931aa6a5cf83524fb677ce/crawlerByTimos_node_modules_bcrypt-pbkdf_index.js

So what I’ve been mulling over is to just port that instead of trying to come up with a brand new green field implementation. If even that doesn’t yield an acceptably fast OpenSSH encrypted key I should at least be able to share a small code samples showing Javascript’s speed vs PHP’s speed. Like right now the best I can do is share one big program vs another big program and that’s not as convincing a demonstration as a small 3 line code snippet would be.

I mean, just considering the history of Javascript vs PHP it isn’t all that surprising that Javascript would be loads faster. Javascript has big money behind it. The PHP Foundation has an annual budget of $600k per https://opencollective.com/phpfoundation#category-BUDGET . Google’s V8 engine probably has whole teams of devs working on it, of which prob 25% of the devs make $500k+ a year. PHP can’t compete with that.

So is there no chance of phpseclib ever supporting ed25519 SSH key passphrases? That seems to be the most recommended key type these days and my use case requires a passphrase. I currently use RSA keys but ed25519 is theoretically faster.

Waiting 30-60s doing it with pure PHP is obviously a non-starter. I am thinking that maybe there is some 3rd party library that supports it or will in the future.

https://github.com/openssh/openssh-portable/blob/master/openbsd-compat/bcrypt_pbkdf.c

@terrafrost

I have an update, “it worked”.

While I tried using file_get_contents in one of the manually managed server setup on ubuntu/centos, I somehow replaced that code with private key path directly, as posted in the sample code in this github issue, when keys are created and code was later uploaded on this cpanel control panel managed centos server.

replaced: $key = \phpseclib3\Crypt\PublicKeyLoader::load('/home/cccv3/.ssh/id_rsa', 'gIoNocxIp08y');

with: $key = \phpseclib3\Crypt\PublicKeyLoader::load(file_get_contents('/home/cccv3/.ssh/id_rsa'), 'gIoNocxIp08y');

while commenting the key reading line of code inwhich I had copied private key content directly.

key takeaways:

• When deploying code on manually managed servers (when server management control panel is not used), I need to check for open_basedir restrictions and deploy code inside “/home/username/public_html” kind of paths instead of other places like “/usr/share/nginx/html”
• permissions of id_rsa: 0600 and .ssh folder: 0700 are fine by default
• I need to ensure RSA private key has to be generated for phpseclib to use and not openssh encrypted key.

thank you

It’s possible that PHP is running as a different user (say www-data) than the user that owns the key. This would be a problem because OpenSSH won’t use the key if the permissions are too open.

A few ideas:

• You could make the web server run with the same account you login as (probably not a good idea)
• You could make the key hard-coded in PHP (how often does it change, anyway?)
• You could password protect the key and put the new key in the same path as your code
• Maybe setting up an ssh-agent would help. See https://phpseclib.com/docs/auth#ssh-agent for more info

please also confirm if SSH-keygen can be used to generate SSH authentication keypairs irrespective of operating system it is generated upon (like CentOS/Ubuntu/RHEL etc…)? or do I need to be mindful in terms of if OpenSSH related bcrypt encryption is used or not by observing the key header before trying with phpseclib library?

It depends more on the version of OpenSSH being used. Looking at the changelog’s it looks like it was OpenSSH 7.8 that introduced the change:

 * ssh-keygen(1): write OpenSSH format private keys by default
   instead of using OpenSSL's PEM format. The OpenSSH format,
   supported in OpenSSH releases since 2014 and described in the
   PROTOCOL.key file in the source distribution, offers substantially
   better protection against offline password guessing and supports
   key comments in private keys. If necessary, it is possible to write
   old PEM-style keys by adding "-m PEM" to ssh-keygen's arguments
   when generating or updating a key.

Got it - I’ll take a look later today!

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,0142FBDB17703DC6576C4A30982EBF96

That’s not an OpenSSH formatted key. An encrypted OpenSSH key starts off with -----BEGIN OPENSSH PRIVATE KEY-----. Apologies for assuming that it was.

Private keys of the format you posted are supported.

If you can generate a private key that’ll duplicate the issue - or are willing to share that private key with me - could you do so so that I might be able to reproduce the key? You can email it to terrafrost@php.net if you want!