OK, so they are fine at that - and you should be able to SSH onto the server.
If you create a second user account on the server - give it sudo permissions.
If you then run through adding certbot etc and check what the permissions are as you go, and that you can still SSH on. If you get to a position that you can’t SSH into the server on that account, the other account should still work and you can see what the permissions are, and what commands were the latest used before you could no longer connect via SSH.
OK, will try tomorrow. Its 10pm over here. Really appreciate your help even though I didnt expect it would be that complicated to set up. As having HTTPS is becoming very important, I do like to see it working out properly.
the last command I use is the letsencrypt installer sudo ./letsencrypt-auto certonly --webroot -w /opt/bitnami/apps/wordpress/htdocs -d DOMAIN
Now this morning I was pondering about the issue again.
you mentioned the following things:
So you should be able to SSH into it. As long as Firewalls Rules are set ok
OK, so it’s not a firewall issue.
incorrect permissions can cause the messages you are seeing.
it’s permissions of the files, not the CPU
permissions of .ssh are fine
What are the permissions of the files Let’s Encrypt creates? Could these be possibly different from the original GCE files and therefor being block cause of security issues?
The “file permissions” I mentioned were those in ~/.ssh/ so not the same as the letsencrypt files. If letsencrypt changed these by default this forum would be full of people not being able to ssh in. I’ve only seen one similar issue ( and that wasn’t that they couldn’t ssh in, it was that certbot ran every time they connected via SSH ( they had made a mistake installing it ).
Have you checked the permissions before and after running each command as suggested ? and used a seperate user account to ensure you can still ssh in ?
as above "The file permissions I mentioned were those in ~/.ssh/ "
~ is the convention for your home directory. If you are logging in as the root user then this would be /root/ so the permissions I was referring to were /root/.ssh and the files within that directory.
If you are logging in as use "jdoe" then ~ would normally be /home/jdoe/ so the ~/.ssh folder would be /home/jdoe/.ssh
I did as you suggested. I did each step and monitored closely if there were any permissions being changed.
That didnt happen. From beginning until the end the
~/.ssh had permissions (700)
~/.ssh/authorized_keys (600)
The moment I was denied access to SFTP is right after I run the Client.
For the SSH console, we have access until we close the window.
I dont know if its related, but share my observations.
in ~/tmp, besides the /letsencrypt/ folder, it slso created another folder ~/tmp/ssh-ABC123xyz0 Im not sure where it is for
I’m not sure if you missed my last question “OK, did you have a second ssh user, and the permissions are still that after the client and you can still no longer connect via SSH on that account ?”
I didnt miss it. I did create a second SSH user and premissions stayed the same.
BUT finally, 2 days ago we managed to solve the issue permanently. First we did the approach of using the WP Encrypt plugin for wordpress. This helped us understand that the folder the Letsencrypt Client was installed in, was incorrect.
When installing the client you will need to remember that /opt folder is for third party apps so you need to clone the letsencrypt in that folder.
Also it is very important to STOP THE SERVER before running the client. /opt/bitnami/ctlscript.sh stop
At the end we ran CERTBOT (LETS ENCRYPT) WITH THE --STANDALONE PARAMETER sudo -H ./certbot-auto certonly --standalone -d <DOMAIN_NAME> -d www<DOMAIN-NAME>
Thank you for your help. You definitely helped us further and we were encouraged by your quick replies. That pushed us through!
