/recovery is 404ing on a fresh install

vacri · November 14, 2019, 12:30am

I’m setting up a demo server, and I’ve run into two problems.

/recovery is 404ing

There’s no magic proxying going on, I’m also able to log into the web console and manage my account fine. I haven’t done much exploration yet (see 2) below), but a missing /recovery page seems like it’ll be an issue.

how to reset a broswer plugin/account?

Currently I’m trying to test with FF and Chrome, and I’m using my demo server. As far as I can tell, the plugin supports single accounts only (unless you go multi-account in chrome itself… which is not something I want to do with non-techie endusers). I’d like to roll out this demo to some select users to try out, but first I want to figure out how to zap the details so we can use a production setup after we’re done with the demo. I didn’t find any good documentation on how to do this (and is what led me to find that /recovery is 404ing)

Setup:

fresh debian 10 VM, basically vanilla debian + basic php setup (our php SOE - I had to turn php-fpm + nginx off so the installer script would work properly; can’t usermod www-data if it’s in use)
AWS EC2 instance behind an AWS load balancer
running a self-signed cert on 443 (the loadbalancer holds a valid cert for the web)
was installed using the official documentation for debian 10 and the installer script 2 days ago
did the initial script installation with LetsEncrypt, that failed, so reran the installation with self-signed certs instead
using a remote mysqldb

logs/error.log - mostly just repeats of the following:
2019-11-14 00:08:46 Error: [Cake\Routing\Exception\MissingRouteException] A route matching “/recovery” could not be found.
Request URL: /recovery

with occasional:
2019-11-13 03:08:02 Error: [Cake\Http\Exception\ForbiddenException] You need to login to access this location.
Request URL: /auth/is-authenticated.json

Installation log from console, showing choices and results (re-run over previous Lets Encrypt-style deploy)
root@passbolt-demo:~/passbolt-installer# ./passbolt_ce_debian_installer.sh
================================================================
____ __ ____
/ __ ____ _____ / / ____ / / /
/ // / __ `/ / / __ / __ / / _/
/ / // ( | ) // / // / / /
// _,///,/_//_/

      The open source password manager for teams
      (c) 2018 Passbolt SARL
      https://www.passbolt.com
================================================================
IMPORTANT NOTE: This installation scripts are for use only
on FRESH installed debian >= 9.0 | ubuntu 18.04 | CentOS >= 7.0
================================================================
==============================================================
Do you want to install a local mariadb server on this machine?
==============================================================
1) yes
2) no
#? 2
================================================================================
On virtualized environments GnuPG happen to find not enough entropy
    to generate a key. Therefore, Passbolt will not run properly.
    Do you want to install Haveged to speed up the entropy generation on
    your system? Please check https://help.passbolt.com/faq/hosting/why-haveged-
virtual-env
================================================================================
1) yes
2) no
#? 1
================================================================================
Setting hostname...
    Please enter the domain name under which passbolt will run.
    Note this hostname will be used as server_name for nginx
    and as the domain name to register a SSL certificate with
    let's encrypt.
    If you don't have a domain name and you do not plan to use
    let's encrypt please enter the ip address to access this machine
================================================================================
Hostname:passbolt-demo.mydomain.net
================================================================================
Setting up SSL...
    Do you want to setup a SSL certificate and enable HTTPS now?
    - manual: Prompts for the path of user uploaded ssl certificates and set up 
nginx
    - auto:   Will issue a free SSL certificate with https://www.letsencrypt.org
 and set up nginx
    - none:   Do not setup HTTPS at all
================================================================================
1) manual
2) auto
3) none
#? 1
Enter the path to the SSL certificate: /etc/ssl/passbolt-selfsigned.crt
Enter the path to the SSL privkey: /etc/ssl/passbolt-selfsigned.key
usermod: no changes
=============================
Installing os dependencies...
=============================
Hit:1 http://security.debian.org/debian-security buster/updates InRelease
Hit:2 https://packages.sury.org/php buster InRelease
Hit:3 http://cdn-aws.deb.debian.org/debian buster InRelease
Hit:4 http://cdn-aws.deb.debian.org/debian buster-updates InRelease
Hit:5 http://cdn-aws.deb.debian.org/debian buster-backports InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
git is already the newest version (1:2.20.1-2).
nginx is already the newest version (1.14.2-2+deb10u1).
php-gnupg is already the newest version (1.4.0-3).
certbot is already the newest version (0.31.0-1).
unzip is already the newest version (6.0-23+deb10u1).
php-pear is already the newest version (1:1.10.9+submodules+notgz-1+0~20191010.12+debian10~1.gbp296d25).
php7.3-dev is already the newest version (7.3.11-1+0~20191026.48+debian10~1.gbpf71ca0).
php7.3-fpm is already the newest version (7.3.11-1+0~20191026.48+debian10~1.gbpf71ca0).
php7.3-gd is already the newest version (7.3.11-1+0~20191026.48+debian10~1.gbpf71ca0).
php7.3-intl is already the newest version (7.3.11-1+0~20191026.48+debian10~1.gbpf71ca0).
php7.3-ldap is already the newest version (7.3.11-1+0~20191026.48+debian10~1.gbpf71ca0).
php7.3-mbstring is already the newest version (7.3.11-1+0~20191026.48+debian10~1.gbpf71ca0).
php7.3-mysql is already the newest version (7.3.11-1+0~20191026.48+debian10~1.gbpf71ca0).
0 upgraded, 0 newly installed, 0 to remove and 7 not upgraded.
============================================
Using remote or custom database installation
============================================
Synchronizing state of php7.3-fpm.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable php7.3-fpm
Already up to date.
/root/passbolt-installer
======================
Installing composer...
======================
--2019-11-13 01:02:28--  https://getcomposer.org/installer
Resolving getcomposer.org (getcomposer.org)... 142.44.245.229, 2607:5300:201:2100::4:d105
Connecting to getcomposer.org (getcomposer.org)|142.44.245.229|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 275959 (269K) [application/octet-stream]
Saving to: ‘composer-setup.php’

     0K .......... .......... .......... .......... .......... 18%  205K 1s
    50K .......... .......... .......... .......... .......... 37%  206K 1s
   100K .......... .......... .......... .......... .......... 55% 18.6M 0s
   150K .......... .......... .......... .......... .......... 74%  207K 0s
   200K .......... .......... .......... .......... .......... 92% 22.1M 0s
   250K .......... .........                                  100% 25.9M=0.7s

2019-11-13 01:02:30 (367 KB/s) - ‘composer-setup.php’ saved [275959/275959]

All settings correct for using Composer
Downloading...

Composer (version 1.9.1) successfully installed to: /usr/bin/composer.phar
Use it: php /usr/bin/composer.phar

===================================
Installing composer dependencies...
===================================
Loading composer repositories with package information
Installing dependencies from lock file
Nothing to install or update
Generating optimized autoload files
> Cake\Composer\Installer\PluginInstaller::postAutoloadDump
thadafinser/package-info:  Generating class...
thadafinser/package-info: ...generating class
> App\Console\Installer::postInstall
No Security.salt placeholder to replace.
===================
Setting up nginx...
===================
Server names hash bucket is 64
Synchronizing state of nginx.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable nginx
Server names hash bucket is 64
Synchronizing state of nginx.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable nginx
Hit:1 http://cdn-aws.deb.debian.org/debian buster InRelease
Hit:2 http://cdn-aws.deb.debian.org/debian buster-updates InRelease
Hit:3 http://cdn-aws.deb.debian.org/debian buster-backports InRelease
Hit:4 http://security.debian.org/debian-security buster/updates InRelease
Hit:5 https://packages.sury.org/php buster InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
haveged is already the newest version (1.9.1-7).
0 upgraded, 0 newly installed, 0 to remove and 7 not upgraded.
Synchronizing state of haveged.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable haveged
================================================================================
Installation is almost complete. Please point your browser to
  https://passbolt-demo.mydomain.net to complete the process
================================================================================

How do I get the /recovery location working? And what’s the best way to reset the credentials for the browser plugins?

Thanks,

Paul

vacri · November 14, 2019, 12:47am

Also, sometimes (not always), I get one or more ‘not authorized’ messages on the /recovery 404, and in the app error log, there are no auth loglines with the same datestamp. The above pic was from a chrome private window (no passbolt plugin)

garrett · November 14, 2019, 3:22am

Regarding the recovery errors… Possibly a file ownership or permissions issue somewhere in a subfolder?

vacri · November 15, 2019, 12:18am

All the files are owned by the webserver user. Log dir and tmp dir inside the app directory are both a+rwx. I haven’t done any perms changes at all. The only thing like this was that nginx + php-fpm were running the first time I ran the install script, which exited at the ‘usermod’ item in the install script - it wants to change the homedir of www-data so it can store composer cache and gpg items. But all of that is owned by www-data as well.

root@passbolt-demo:/var/www/passbolt# find . -printf '%u\n' | sort | uniq -c
    4077 www-data

root@passbolt-demo:/home/www-data# find . -printf '%u\n' | sort | uniq -c
    134 www-data

I might try a fresh install next week on a stock debian.org image, rather than our php soe (there isn’t that much extra in our soe, though).

garrett · November 15, 2019, 1:23am

It’s actually “/recover” and not “/recovery”…just verified it. Sorry, should have thought of that sooner.

When you say “reset” a user account, what do you mean exactly? Keep the user account but clear out passwords?

EDIT: I see you mentioned “clear credentials”…you are wanting to keep the user account but remove the password and associated key maybe?

vacri · November 15, 2019, 5:52am

Ugh, brought low by a typo. In my mind I was typing /recover, but the logs and screenshots don’t lie. Thank you for that. Sorry, doing several things at once.

By ‘reset a user account’, I mean ‘wipe from the user’s own machine’, to remove their current account using the demo server and start afresh with a new account using the real production server. I don’t want to keep the demo accounts at all. From my small amount of playing with my demo setup so far, the plugin doesn’t handle account switching or dropping accounts.

I didn’t find clear docs on how to do this, though I haven’t exactly proven myself as the best troubleshooter so far

garrett · November 15, 2019, 11:39am

Being able to switch accounts in the plugin would be nice, as would pushing out a “self-destruct” notice from the server if there is a permanent account removal required. Consider adding to the wish list if it’s not already there, but no I don’t think those are current features.

You would know your situation the best, and I share only to be helpful, but in my experience getting non-techie folks to the “plugin installed and working” stage is no small feat. With proper preparation you could transfer keys (server’s and users’) to production in the new db. That puts the difficult work on your end, rather than on the end user. Of course, if they delete their “demo, but also production” key, this is also a good time to learn what that means as well.

Maybe this doesn’t help at all, but it was just a thought.

vacri · November 17, 2019, 11:53pm

Thanks for the ideas, Garrett, food for thought. There must be a way to zero the config on the plugin, though, for testing and similar. I’d like to play around with some common scenarios myself before rolling it out to the demo group, to see how the recovery process works, what steps users need to take to restore on the ‘happy path’, the non-happy path, etc.

Re: the demo users themselves, they’d be other members of the tech team. Not necessarily security oriented, but used to pawing through filesystems and such, so they can follow a list of steps without too much worry

(From previous experience with team password managers, you can take an end-user, sit them down personally for 5 minutes, look them in the eye and say “I know that you get ‘don’t forget this password/whatever’ often, but this one you really can’t lose; I cannot reset it”, have them convincingly say “yes, I understand”, and a week later have the same person ask for it to be reset because they forgot… that particular person was a senior backend dev, too…)

system · November 22, 2019, 11:53pm

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.