DK0029 Error - Unprotected private key file

Q: Date/Time this occurred (Provide your time zone also)
**A: 2/9/2022 - 2/10/2022 multiple times **

Q: DevKinsta Version
**A: 2.4.0 **

Q: OS Version
**A: Windows 11 Pro 22000.493 **

Q: Docker Desktop Version
**A: 4.4.4 (73704) **

Q: Were any error codes or messages observed? If so, what were they?
**A: DK0029 **

Q: Detailed Description of the Problem
Trying to import a site and getting the DK0029 error, but it seems to be different than the other issues people have had regarding that error. The Kinsta log:

[2022-02-10 10:51:54.131] [error] Error - DK0029: MYSQL_DUMP_COMMON: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@Permissions 0755 for '/root/.ssh/id_rsa' are too open.It is required that your private key files are NOT accessible by others.This private key will be ignored.Load key "/root/.ssh/id_rsa": bad permissions
    at file:///C:/Users/Matt/AppData/Local/Programs/DevKinsta/resources/app.asar/dist/
    at tryCatch (file:///C:/Users/Matt/AppData/Local/Programs/DevKinsta/resources/app.asar/dist/
    at Generator._invoke (file:///C:/Users/Matt/AppData/Local/Programs/DevKinsta/resources/app.asar/dist/
    at (file:///C:/Users/Matt/AppData/Local/Programs/DevKinsta/resources/app.asar/dist/
    at asyncGeneratorStep (file:///C:/Users/Matt/AppData/Local/Programs/DevKinsta/resources/app.asar/dist/
    at _next (file:///C:/Users/Matt/AppData/Local/Programs/DevKinsta/resources/app.asar/dist/
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

I’m not quite sure which id_rsa it’s referring to though. The only container I could find with the file is devkinsta_fpm and I tried chmod 600 /root/.ssh/id_rsa but that didn’t fix it.

I’ve also tried deleting all sites in DevKinsta, all devkinsta_ containers, uninstalling DevKinsta and reinstalling and no dice either.

Help please!

Hi @mattd, thanks for reaching out. I’m trying to figure out what would actually cause this as well. Is this happening with ANY site you try to import?

Are you able to create a new WordPress website within DevKinsta without issue? If you can share your main.log file after this failure, I can share it with our devs to hopefully get more insight.

Hi @Kevin,

Yeah, it’s happening for every site :confused:

Creating a new WordPress site within DevKinsta works fine.

And I’ve DM’d you the main.log file.


1 Like

Thanks for sharing that, @mattd! I’m going to have our Devs look into what might be happening there.
I also would recommend doing a factor reset of Docker before trying again. I checked your site within MyKinsta for abnormalities and nothing stood out to me, although there could be something that the Devs can spot.

Were you copying the Live site from MyKinsta or the Staging?

Great, thanks @Kevin. It happens for both Live and Staging for every site.

1 Like

Hi @mattd, I believe I’ve figured out what is causing this. There’s something wrong with the id_rsa that is within DevKinsta’s .ssh directory.

Quick fix:

  1. Close DevKinsta then navigate to your DevKinsta directory (C:\Users\myuser\DevKinsta)
  2. Delete the .ssh directory
  3. Open DevKinsta and log out of your MyKinsta account
  4. Logging back in should recreate the .ssh directory with the correct permissions

Please let me know if doing this still leads to the same private key error. You’re not the only person to have this error on Windows but I’m still not sure what exactly is causing it.

Thanks for the suggestion @Kevin. I’m afraid it didn’t work though :confused: I followed the steps and the .ssh directory was recreated like you expected, but attempting to import a site still gives the same error.

Huh very odd. So can you open WSL console then navigate to the DevKinsta/.ssh directory and check the permissions that are being set for id_rsa?

  1. Open a WSL console
  2. cd /mnt/c/Users/username/DevKinsta/.ssh
  3. ‘stat id_rsa’
  4. “Access” will tell you the permissions

Whatever WSL sees here seems to be what DevKinsta sees as the file permissions. I feel like the permissions aren’t being set correctly by your PC for some reason.

Matt@Matt-PC D:/Dev/DevKinsta/.ssh
10:16:05 ❯ ls -la
total 5
drwxr-xr-x 1 Matt 197609    0 Feb 16 08:23 ./
drwxr-xr-x 1 Matt 197609    0 Feb 16 08:20 ../
-rw-r--r-- 1 Matt 197609 2602 Feb 16 08:23 id_rsa
-rw-r--r-- 1 Matt 197609  571 Feb 16 08:23

Matt@Matt-PC D:/Dev/DevKinsta/.ssh
10:16:06 ❯ stat id_rsa
  File: id_rsa
  Size: 2602            Blocks: 4          IO Block: 65536  regular file
Device: 9c1b5385h/2619036549d   Inode: 153122387330928527  Links: 1
Access: (0644/-rw-r--r--)  Uid: (197609/    Matt)   Gid: (197609/ UNKNOWN)
Access: 2022-02-16 10:16:06.642244400 -0600
Modify: 2022-02-16 08:23:19.725450900 -0600
Change: 2022-02-16 08:23:19.725450900 -0600
 Birth: 2022-02-16 08:23:19.722949400 -0600
1 Like

In your main.log, is it saying the id_rsa permissions are 644? Or is it still saying they are 755?

Just tried importing again, it says 755:

[2022-02-16 10:24:46.352] [error] Error - DK0029: MYSQL_DUMP_COMMON: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ WARNING: UNPROTECTED PRIVATE KEY FILE! @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@Permissions 0755 for '/root/.ssh/id_rsa' are too open.It is required that your private key files are NOT accessible by others.This private key will be ignored.Load key "/root/.ssh/id_rsa": bad permissions

So /root/.ssh maps to C:/Users/user/DevKinsta/.ssh, or is the error referring to a different location?

So I was looking at this based on a site Push; that’s where the id_rsa is in that case. Looking at your original error it’s probably due to the id_rsa on Kinsta since you’re doing a Site Pull. I’m working on this right now/trying to reproduce the error exactly as it’s showing for you.

I’ll see if any permissions on Kinsta need to be changed. Do you mind if I only look into your Staging site? Don’t want to do anything that affects the Live site.

By the way @mattd, version 2.4.1 was just released. I really doubt any of the bugfixes will affect this but it’s worth updating/trying just in case.

Hey @Kevin, unfortunately the new version didn’t fix it, but unsurprising if the issue is server-side.

But sure, you can check out our staging. I’ll DM you with the account.


1 Like

Thanks @mattd;
So I’ve finally been able to reproduce the exact error you are having and I think my original conclusion is correct. For some reason the permissions for .ssh/id_rsa are not being set correctly. Are you logged in as the root/admin user? Looking back at your stat id_rsa, I notice that your Access/ Uid and Gid don’t match what I get as the root/main user on my computer:

Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root)


Access: (0644/-rw-r–r–) Uid: (197609/ Matt) Gid: (197609/ UNKNOWN)

Maybe you need to delete the .ssh directory again and make sure you’re running DevKinsta as the administrator when you log into your Kinsta account? Also if you have another PC that you can use to test, that would help, too.

The mysqldump command uses the SSH credentials on your computer to connect to the Kinsta site. I’ve spent a couple of hours trying to figure out how to manually set the file permissions from within Windows but for whatever reason nothing as simple as “chmod” and “chown” exists for Windows. It is interesting that your permissions aren’t being set the same way as mine on my computers, though.

I think if you install DevKinsta on the main/admin Windows account you can get past this. I’ll keep trying to reproduce this but admin privileges/permissions seems like the best thing to look into.

I did mention this to our devs and they may look into ignoring this permissions notice so that it doesn’t cause import/export to fail.

Hi @Kevin, I tried logging out of DevKinsta, exiting the app, deleted the .ssh directory, opened DevKinsta with admin privileges, and logged back in… and no dice :frowning:

The .ssh directory was re-created, but stat id_rsa is still showing my UID, not root.

I tried importing a site again anyways and still the same error.

FYI, I’m running Docker Desktop with the Hyper-V backend (vs WSL 2) as discussed here if that matters.

Thanks for trying @mattd; I’m still not sure what’s causing this for certain Windows users but the permissions on that file are definitely the issue. I’ve used this week’s troubleshooting to bring this up with the Devs. I’ll be sure to update you if they can think of a workaround or solution.

Thanks again for working with me on this one. It’s a very odd issue.

1 Like

Hey @mattd, I’ve been discussing ways to resolve this in future versions with our devs but I’ve been looking into quick fixes. Using Hyper-V might be causing the difference in permissions when the file is created but I haven’t been able to reproduce your setup yet.

Can you see if running this in the DevKinsta/.ssh directory helps with the folder permissions? If you can stat the file again after that would be helpful:

sudo cat id_rsa > id_rsa2 && chmod 600 id_rsa2 && rm id_rsa && mv id_rsa2 id_rsa

If the user/group still look weird, you might have to chown yourusername:yourusername id_rsa

Hi @Kevin, working from the office today (first time since the issue) and crazy enough, I’m getting the same exact error on my work machine. Totally different computer, network, etc. Similarities are that it’s Windows 10 Pro and Hyper-V backend for Docker Desktop.

I tried running the command(s) you suggested but still no luck. (I think the 2nd command was supposed to be chown not chmod?)

Not sure if I mentioned this before, but both my work and home PCs ran DevKinsta just fine until recently when this error popped up. Honestly not sure if it was after a specific update though…

Thanks @mattd,
Yes, chown, sorry! Yes there have been a lot of updates lately but I’m not sure what would cause this. There’s a small handful of people having the same issue but I don’t think everyone is using a Hyper-V backend setup.

I guess I’ll just try to emulate your setup sometime. By the way, did manually creating a new id_rsa still leave you with 644 permissions on that file?