Anybody have any suggestions on what might be the issue, or has anyone experienced anything similar?
I’m having trouble making a connection to my server using RapidWeaver’s 8.2 SFTP publishing setting (but it was also happening in 8.1.7). I use public/private key authentication to connect, and it works fine when I connect through my Terminal (can establish an SFTP connection without any kind of issue), but when I try to test the connection in the RapidWeaver publishing settings, I get the below error:
I enabled the Publishing logging, and below is the output of that:
2019-05-24 xx:xx:xx.xxx RapidWeaver 8[5337:502425] [0] Trying xxx.xx.xx.xx…
[0] TCP_NODELAY set
[0] Connected to xxx.xx.xx.xx (xxx.xx.xx.xx) port 22 (#0)
[0] SSH MD5 fingerprint: xxxxxxxxxxxxxxxxxxxxxxx
[0] SSH authentication methods available: publickey
[0] Using SSH private key file ‘/Users/xxxxxxxxxxxxx/.ssh/id_rsa’
[0] SSH public key authentication failed: Unable to extract public key from private key file: Wrong passphrase or invalid/unrecognized private key file format
[0] Authentication failure
[0] Closing connection 0
I don’t understand why the error says “wrong passphrase or invalid/unrecognized private key file format” when it works just fine when connecting from Terminal:
I’m not using a password, I’m using public/private key authentication. The password field is left blank in RapidWeaver’s publishing settings, only the passphrase field is completed.
RapidWeaver is saying " Wrong passphrase or invalid/unrecognized private key file format" which doesn’t make sense considering I can connect through SFTP via Terminal, or any other SFTP client.
Is there a reason why you are using the passphrase option with SFTP?
I’ve been using SSH and SFTP for years at multiple clients but can’t remember the last time I saw a passphrase being used.
The passphrase only provides additional security on the client side (your mac In this instance) by encrypting the private key stored there(~/.ssh/id_rsa).
Don’t know if this is causing the problem but looking at the log entry you posted(assuming the parts you x’ed out match) I would try regenerating the public and private keys without a passphrase and see if that connects.
Passphrases were mainly designed for keys belonging to interactive users like a terminal user. For automatic processes like an ftp client or RapidWeaver the passphrase is stored so it doesn’t make sense to use one since anyone that has access to these apps has access to the passphrase.
Is there a reason why you are using the passphrase option with SFTP?
Yeah, because I always protect my public/private keys with a passphrase. I don’t feel I should have to not use a passphrase for the connection in RapidWeaver to work, especially since it provides the option for public/private key authentication to be used.
I was suggesting that you “try” without the “passphrase” as an attempt to debug the publishing issue. Still using public key authentication, just no passphrase.
Since the passphrase is optional and only protects the private key stored on your Mac removing it shouldn’t create any security risk. I think it would be a good first step in the debugging process.
My only other suggestion would be to contact realmac support support@realmacsoftware.com with all the logs and information you have.
I had the same problem. In my case, the error was caused the format of the private key (password protected or not does not matter.) - The default has changed from PEM to RFC4716.
Here is how to diagnose it:
If your private key starts with -----BEGIN OPENSSH PRIVATE KEY----- it is the wrong type (RFC4716), RW8 does not seem to read it (might be ssh-library related)
If your private key starts with -----BEGIN RSA PRIVATE KEY----- it might be the correct type (PEM). If the access still fails, enable verbose ssh logging.
Solution that worked for me:
a) Best option is to generate a new key with the option -m PEM (also ssh-keygen -m PEM). I did that. Now it works.
b) You can convert key with the option ssh-keygen -e -m PEM -f PathToKeyfile . It should work with already established keys, but that failed for unknown reasons for me and I decided not to persue.
Thanks. I’m not particularly competent on ssh, but I had some issues with certificate types before …
Can I suggest a way to fix this issue?
A “quick” fix might be a specific help text for the dialog choosing the certificate. Say “PEM” format and give a syntax example for the key generation.
Also, RW could mention the necessary key type in the error message. Right now, it points the mind to a “password” or file problem, but not to the encoding of the certificate.
A deeper handling of the issue could consist of checking the certificate type (rfc4716 see below vs pem - https://tools.ietf.org/html/rfc1421) in the code. This can be done by using the formating rule for 4716 certs - see here https://tools.ietf.org/html/rfc4716#section-3.5 - five dashes (pem) vs. four (4716). This would enhance the error message.
Just had a chance to test it and wanted to come back and say thank you so much for taking the time to write up the solution. I appreciate your time. Virtual beers for you!
…
