Passport: "storage/oauth-private.key" does not exist or is not readable.

[siarheipashkevich]

Hi, today I updated composer and I got this error:
Operation failed: Operation not permitted

I have resolved this probem by running the following commands:
chmod 600 storage/oauth-private.key
chmod 600 storage/oauth-public.key

But then I got the following error:
"storage/oauth-private.key" does not exist or is not readable

Thanks for help

[alexbilbie]

@siarheipashkevich you need to ensure that the PHP process owns the private and public keys

[siarheipashkevich]

@alexbilbie could you please help me how can I check it?

[blablahaha]

I think you didn't correctly install passport.

Please run this command:

php artisan passport:install

[siarheipashkevich]

@SmileYuhao I ran this command and I have installed keys.

[siarheipashkevich]

@alexbilbie I updated composer packages in the Homestead machine and I am not getting any errors, but in my local machine I get this error. I'm afraid that it will break my prod.

[bassco]

The file permission changes introduced in 2.0.11 have been disastrous for us too. We host our laravel containers and publish the shared oauth keys via secret files using volume mounts in a kubernetes cluster.

The website runs under user _www-data_, but the secret files are mounted and owned by _root_.

We are pegging our application at 2.0.10 as we are unable to change the ownership of the files.

[jspicee]

Same issue

[lomby]

We are also experiencing this issue over the last couple of days. The only workaround for us was to set the owner of these two files to www-data manually when they have always been root previously.

[maurice-ellis]

The version 5.1.4 of LeagueOAuth2Server has a change that needs to be update in Passport.

https://oauth2.thephpleague.com/v5-security-improvements/

[shailesh87]

I am also facing same issue after composer update.

[andrefigueira]

Same issue here after a composer update, running in docker container, which by default runs everything as root. As @alexbilbie just need to make sure the keys are owned by PHP and it solves the problem, so it's not so much that the package broke anything but we've had it configured incorrectly and didn't read release notes and update our applications accordingly.

Check the ownership of the files easily using `ls - e.g.

[root@air-queue-workers notifications]# ls -l storage/
-rw------- 1 1001 root     3292 Jul  6 10:27 oauth-private.key
-rw------- 1 1001 root      812 Jul  6 10:27 oauth-public.key

Then just correct with chown or whatever way you automate your project setup...

chown correctuser:correctgroup storage/oauth-*.key

[iget-esoares]

This issue is causing big problems here.

The file should be owned by www-data when accessing on web, and by myuser when accessing artisan tinker, because it try to run chmod, that can only be called by file owner (or root).

[Wolg]

Having the same issue with Envoyer deployment.
when deploying and performing php artisan optimize we need those files to belong deployment user (ec2-user on aws). But it will break entire application 'cause when accessing on web it should belong to web-server user (nginx).

[andrefigueira]

@iget-esoares from what I can see in the code, it only attempts to run the chmod when the permissions are incorrect, so you could circumvent by having the permissions set at a higher level, for example your provisioning tool or deployment tool.

[shailesh87]

In the centos linux the command chown apache:apache /storage -R work for me.

[libasoles]

Well, according to /vendor/league/oauth2-server/src/CryptKey.php both files must be _chown_ to http server (nginx/apache/whatever) and permissions set to 0600. Like:

sudo chmod 0600 storage/oauth*
sudo chown http:http storage/oauth*

Personally I dislike this. it breaks our existing code and forces me to set the user (not only the group) to http server.

This is the problematic commit: https://github.com/thephpleague/oauth2-server/commit/2f8de3d2302beb490abb9475cf426148801c25c4

[libasoles]

Things are being quite in _phpleague_ repo:
https://github.com/thephpleague/oauth2-server/issues/760

[alexbilbie]

I have released 5.1.5 which replaces the hard errors with notices and deprecation warnings.

It is correct behaviour that the key should be owned by the server process to prevent possibility of token forgery by replacing the server’s public key or leakage of the key by an attacker or rogue other process.

[vdjkelly]

chmod(/var/www/sanidad/storage/oauth-public.key): Operation failed: Operation not permitted

help me

[ryankazokas]

@andrefigueira i changed ownership of the keys to www-data and the permissions to 0600 within the docker container and now I'm getting an error prior to that when it is trying to find if the file is readable? Has this been happening to anyone else? Even if i keep the perms at 0600 and change the user;group back to root:root there is the same issue. This is tag 5.1.5 that has the notice instead of exception.

(1/1) LogicExceptionKey path "file:///var/www/storage/oauth-private.key" does not exist or is not readable

in CryptKey.php (line 44)

[libasoles]

@ryankazokas it's not root:root, but _server:server_ (meaning apache2:apache2, http:http, or whatever user you have in your server)

[ryankazokas]

@libasoles , you are correct, i was able to find the correct user/group combo for my apache2, but now I'm receiving:

(1/1) ErrorExceptionYou must set the encryption key going forward to improve the security of this library - see this page for more information https://oauth2.thephpleague.com/v5-security-improvements/

in AuthorizationServer.php (line 142)
at HandleExceptions->handleError(16384, 'You must set the encryption key going forward to improve the security of this library - see this page for more information https://oauth2.thephpleague.com/v5-security-improvements/', '/var/www/vendor/league/oauth2-server/src/AuthorizationServer.php', 142,array('grantType' => object(AuthCodeGrant), 'accessTokenTTL' => object(DateInterval)))

i confirmed that the permissions are 0600.

-rw-------  1 laradock laradock  812 Jul 13 03:15 oauth-private.key
-rw-------  1 laradock laradock 3292 Jul 13 03:15 oauth-public.key

[libasoles]

@ryankazokas Well, that's a basic step in Laravel. You must generate an APP_KEY and store it in your .env file. Use: artisan key:generate.

[ryankazokas]

@libasoles i've done this, and just to reassure myself i did it again and still receive the same error. The error seems to be unrelated(although i'm not positive, so i can hack away at it and if i need a new issue thread for that or need to come back, I will go that route. Thanks!

[namelivia]

@libasoles @ryankazokas The unset key that triggers the error is a property called encryptionKey belongin to the class League\OAuth2\Server\AuthorizationServer. This class has a setter method for that property but I've looked through the code and I don't see any call to that method, so it stays as null and the error is triggered.

[ryankazokas]

@namelivia yeah i saw why the exception was happening. Wasn't sure where or why it wasn't being set. What version are you using?

[indra1]

@Wolg just update your envoyer to run chmod at the end to return oauth keys to www-data. I just got this error and i'm still stuck with it

I did this and it worked:
@task('update_permissions')
chgrp -R www-data {{ $app_dir }};
chmod -R ug+rwx {{ $app_dir }};
chown -R www-data:www-data {{ $app_dir }} . '/storage/oauth-*.key';
@endtask

[ryankazokas]

@libasoles @namelivia
I was able to fix this by updating to the newest version(3.0) of laravelpassport
The constructors are different from v2 to v3. https://github.com/laravel/passport/commit/6dc37eb5f8da996409ff041a8de62959dbba0cec

Should the composer file in 2.0.11 and below change the league outh dependency?
currently it is:
"league/oauth2-server": "~5.0",

[Hao-Wu]

Just a quick workaround for this issue, comment out line 142 in /league/oauth2-server/src/AuthorizationServer.php

        if ($this->encryptionKey === null) {
            // @codeCoverageIgnoreStart
            //trigger_error(self::ENCRYPTION_KEY_ERROR, E_USER_DEPRECATED);
            // @codeCoverageIgnoreEnd
        }

the error message is defined in the same class:

    const ENCRYPTION_KEY_ERROR = 'You must set the encryption key going forward to improve the security of this library - see this page for more information https://oauth2.thephpleague.com/v5-security-improvements/';

But please keep in mind that, it is just a quick workaround to let the server work, but not a real fix. We are recommended to upgrad oauth2-server or modify keys.

[ryankazokas]

@Hao-Wu i had to updgrade and modify the permissions of the keys because after I did composer update, it pulls in the newest version of 5.1.5 league/oauth2. This is problematic because laravel/passport 2.0.11 and below due to not pass the key in the constructor when creating the authorizationServer.

[bbdangar]

I am also facing the issue. If you look at the CryptKey.php, it says you must assign 0600 permission to the keys (line 51) and also it should be readable(line 43), to pass this condition you need to assign 0644 permissions to the keys. It fails in one of the conditions. The solution could be changing ownership of the keys. However, I don't know who should be the owner of the keys.

For temporary You can comment line 48 to 68 and change permissions to 644.

[namelivia]

As @ryankazokas previously mentioned, seems that updating passport to 3.0 solved the issue.

[k1m0ch1]

every time I set to the right owner, passport will reset the owner, please fix this without upgrading to 3.0 :(
currently I set the cronjob to the server :(

[bbdangar]

@namelivia mine is already on ^3.0, I mentioned above is in 3.0

[ryankazokas]

@bbdangar Are you sure you are providing the 600 permissions to the correct user. They should be sufficient enough to pass the is_readable method. The same thing happened to me since I am running laradock and docker the user:group combo i needed was laradock:laradock

[bbdangar]

drwxrwxrwx 6 bbdangar bbdangar 4096 Jul 14 13:09 . drwxrwxr-x 13 bbdangar bbdangar 4096 Jun 1 17:20 .. drwxrwxrwx 6 bbdangar bbdangar 4096 Jun 16 18:24 app drwxrwxrwx 2 daemon daemon 81920 Jul 17 21:33 debugbar drwxrwxrwx 6 bbdangar bbdangar 4096 May 11 18:12 framework drwxrwxrwx 2 bbdangar bbdangar 4096 May 30 16:49 logs -rw-r--r-- 1 www-data www-data 3292 Jul 14 16:39 oauth-private.key -rw-r--r-- 1 www-data www-data 812 Jul 14 16:39 oauth-public.key
who is the correct user in this case? bbdangar?? I have tried to change ownership but didn't work. I got it working by modifying CryptKey.php

[etertime]

@libasoles The HTTP server settings owner can solve the problem.,no problem, at least it can run

But the nginx server settings are ineffective, such as:

chmod 600 storage/oauth-p*
chown nginx:nginx storage/oauth-p*

The nginx here is the nginx server user, in the nginx.conf configuration

Result：

-rw------- 1 nginx nginx 3.2K Jul 19 15:03 oauth-private.key
-rw------- 1 nginx nginx  799 Jul 19 15:03 oauth-public.key

Key path "file:///var/www/NewDrugsSuperviseSystemApi/storage/oauth-private.key" does not exist or is not readable

@indra1 Have you tested the nginx server, please?
Who can solve this problem, someone upgraded to 3.0 (#435), or there are problems!

[libasoles]

@etertime I run nginx but inside docker. For me is http:http and it works. Are you using virtualization?

And yes, you'll have to upgrade to Passport 3. No problems.

[alexbilbie]

Please upgrade to Passport 3.0.* to address these issues.

I've pushed a fix to the parent library so that there are no longer any hard errors being thrown if the key files doesn't have 600 permission.

I'm going to close this issue for now. If you're still having issues after upgrading to Passport 3.0.* please open a new ticket and I will try and help you.

[kmligue]

Thanks @libasoles. It fixes my issue. In second command, I changed "http:http" to "www-data:www-data".

[coreation]

@alexbilbie what about L5.3 users? Passport 3.0.* requires Illuminate packages for 5.4... I'm running Passport 1.0 at the moment.

[MrKriegler]

If you are having this issue on mac then

sudo chown _www:_www storage/oauth-*.key

Fixed my issue

[nadeemse]

sudo chown www-data:www-data storage/oauth-*.key
Saved my hours of effort 👍

[adangbryen]

If the file is not exist use the following cmd
```php
php artisan passport:keys

[Braunson]

I had this issue with Jenkins, turned out I just needed to add php artisan passport:keys into my deploy pipeline.

[hemorej]

I'm on Heroku, I've generated the keys with php artisan passport:keys and set the permission to 600 but Passport still complains about the keys

[MrKriegler]

@hemorej you must set the owner of the keys to your web server. On mac this helped me

sudo chown _www:_www storage/oauth-*.key

_www is the apache user find yours and change the owner

[hemorej]

@MrKriegler it's already set to the owner, with 600 as the permission

[hotrush]

I am using passport 5.0 with laravel 5.6. Of course i do not store this keys in vcs, and when i deploy the project first time i get this error at composer install stage.

composer install --no-dev --prefer-dist -o

Loading composer repositories with package information
Installing dependencies from lock file
...
Generating optimized autoload files
> Illuminate\Foundation\ComposerScripts::postAutoloadDump
> @php artisan package:discover

In CryptKey.php line 45:

  Key path "file:///home/.../public_html/storage/oauth-private.key" does not exist or is not readable                                                  


Script @php artisan package:discover handling the post-autoload-dump event returned with error code 1

Of course it does not exist, it does not generated yet!

[hshahdoost]

@hotrush I get the same error on Debian 8, with php7.2 and laravel 5.6

[Razorsheep]

@hotrush I'm getting this too, when I try to enable a custom grant from the AuthServiceProviders boot method. Is there a nice way to check whether the key has been created before I try to enable to grant?

[hotrush]

@Razorsheep i didn't find any good workaround, when deploying first time you just need to generate keys yourself and set valid access rights...

[edgareler]

In my case this issue happened on OAuth login tests when building on CircleCI. I fixed this issue and by generating the OAuth key pair.

steps:
  - run: openssl genrsa -out storage/oauth-private.key 4096
  - run: openssl rsa -in storage/oauth-private.key -pubout > storage/oauth-public.key

I added those steps before PHPUnit step.

[CJDennis]

@edgareler Running those two commands at the command line worked for me.

[hmuntean-ro]

@hemorej you must set the owner of the keys to your web server. On mac this helped me

sudo chown _www:_www storage/oauth-*.key

@MrKriegler thanks for this command, it fixed my problem !

[bluesuiter]

If the file is not exist use the following cmd

php artisan passport:keys

Thank You buddy :)

[nazreen]

my context was that I was running a Gitlab CD pipeline and the laravel app is hosted in an ec2 instance.
because I was using rsync, I had to update the folder permissions recursively to my ec2-user.

the solution for me was to run chown apache oauth-public.key

[ajaymarathe]

I think you didn't correctly install passport.

Please run this command:

php artisan passport:install

this helps me lot :P thanks

[mrhili]

Dont do this line untill you have keys in a specific location for the file

in AuthServiceProvider.php

//Passport::loadKeysFrom('/secret-keys/oauth');

[shivanibenosoft]

Since

I think you didn't correctly install passport.

Please run this command:

php artisan passport:install

Since /storage/*.key is in .gitignore so if you pull the project, that might be missing the key, so running install command create new keys for you

And instead of passport install only generating the new key by running php artisan passport:keys may also help