Lets Encrypt on Wordpress on Google Compute Engine

We have been struggling for long with getting LetsEncrypt running on Google Compute Engine.
On GCE we successfully installed the Bitnami Wordpress on a micro instance.

We do want to have our website secured through Let’s Encrypt. After having succesfully installed the Certificates, Access to SSH and SFTP has been denied.
At this moment I’m even wondering if its even possible to do so. Love to receive some advice…

I ran this command:
Install Git
~$ sudo apt-get install git-all

Change to root access
~$ sudo su

Change to the temporary directory:
~$ cd /tmp

Clone the Let’s Encrypt repository from Github*:
~$ git clone https://github.com/letsencrypt/letsencrypt

Use the cert-auto script to download and install all the necessary dependencies:
~$ cd letsencrypt)
~$ sudo apt-get update
~$ ./letsencrypt-auto

STEP 2: SET A DNS RECORD POINTING THAT DOMAIN NAME TO THE PUBLIC IP ADDRESS OF THE SERVER.
Go to: https://console.cloud.google.com/networking/dns/zones/[zone-name]?project=[project-name]
select the relevant zone.
Create a subdomain and create A record.
Under Data type IP Adress

STEP 3: GENERATE AND INSTALL A CERTIFICATE FOR THE DOMAIN USING THE LET’S ENCRYPT CLIENT?
Change to the directory containing the Let’s Encrypt client.
~$ /tmp/letsencrypt/

Request a new certificate for your domain as below.
~$ ./letsencrypt-auto certonly --webroot -w /opt/bitnami/apache2/htdocs -d DOMAIN
example:

Next, install the generated certificate in your Web server as shown in the next sections.
Run Commands
~$ sudo cp /etc/letsencrypt/live/DOMAIN/cert.pem /opt/bitnami/apache2/conf/server.crt
~$ sudo cp /etc/letsencrypt/live/DOMAIN/privkey.pem /opt/bitnami/apache2/conf/server.key

Restart the Apache server:
~$ sudo /opt/bitnami/ctlscript.sh restart apache

downloaded:
chain.pem
privkey.pem
fullchain.pem
cert.pem

It produced this output:
Unable to access the instance, SSH and SFTP

My operating system is (include version):
Debian 8

I can login to a root shell on my machine (yes or no, or I don’t know):
No anymore after running the script

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
No, as it on Google Cloud Platform

1 Like

Nothing you have done should make any changes to SSH / SFTP

What is tethe detailed message you get when connecting via SSH ? (use ssh -vvv )

This is the message:

Connection Failed
An error occurred while communicating with the SSH server. Check the server and the network configuration.

is that all you get using verbose ( -vvv ) ?

I just tried again… Did some other steps After restarting apache this is the error message:

admin@bitnami-wordpress-dm-cd51:~$ sudo /opt/bitnami/ctlscript.sh restart
apache
Unmonitored apache
Syntax OK
/opt/bitnami/apache2/scripts/ctl.sh : httpd stopped
Syntax OK
(99)Cannot assign requested address: AH00072: make_sock: could not bind to
address 130.211.198.29:80
no listening sockets available, shutting down
AH00015: Unable to open logs
/opt/bitnami/apache2/scripts/ctl.sh : httpd could not be started
Monitored apache
admin@bitnami-wordpress-dm-cd51:~$

I’m confused - how are you using those commands if you can’t SSH. Do you have direct access ?

The apache error and SSH error are 2 different things. which issue do you want to start with ?

For the SSH issue, you need to try running with -vvv on the SSH command line, so you get verbose data.

For the apache issue, something else is listening on port 80 - use “netstat -ltnp | grep ‘:80’” to determine what is listening, then kill that process and restart apache.

second serveco - Google Compute Engine like Azure and AWS is just a platform.

From my understnding of GCE

Bitnami is just a linux stack

So you should be able to SSH into it. As long as Firewalls Rules are set ok

I’m on Trial version for GCP. So basically delete instance when im stuck and try again and change the steps I take

Are you saying that I shoudl somehow add my current IP address to allow access to SSH? any suggestion on ports?

Have you got a firewall set up on the server ? if you haven’t then that shouldn’t be the issue ( and certainly shouldn’t change if all you have done is install HTTPS certs.

As for ports, I personally stick with the default SSH port is most cases.

Only the default ones GCP has standard set up. I basically can’t access from the moment I install the key. I also tried to convert the privkey.pem into ssh-rsa format and added this to the ssh key of GCP. But no success so far.

Would it help if I delete all firewalls GCP has set up?

Thank you. Will do so when I’m back in front of the computer

For ssh, I’d start by seeing exactly what the error is. When it won’t connect, what does the output of ssh -vvvv servername (where servername is the servername or IP address you are connecting to) give ?

You shouldn’t really be adding your private domain key to the SSH.

I ran the ssh -vvvv . This is the result

OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t  3 May 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to <ip-address> [<ip-address>] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: SELinux support disabled
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-5+deb8u3
debug1: match: OpenSSH_6.7p1 Debian-5+deb8u3 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
Connection closed by <ip-address>

OK, so it’s not a firewall issue.

incorrect permissions can cause the messages you are seeing. Did you run a “chown” or “chmod” command during your setup that could have changed the permissions on the .ssh folder ?

I Might, this is what I did when I installed the generated certificates in my web server as shown in the next section:

Run Commands
sudo cp /etc/letsencrypt/live/DOMAIN/cert.pem /opt/bitnami/apache2/conf/server.crt

sudo cp /etc/letsencrypt/live/DOMAIN/privkey.pem /opt/bitnami/apache2/conf/server.key

and

sudo cp /etc/letsencrypt/live/DOMAIN/cert.pem /opt/bitnami/apps/wordpress/conf/certs/server.crt

sudo cp /etc/letsencrypt/live/DOMAIN/privkey.pem /opt/bitnami/apps/wordpress/conf/certs/server.key

sudo chown root:root /opt/bitnami/apache2/conf/server.key
sudo chmod 600 /opt/bitnami/apache2/conf/server.key

sudo chown root:root /opt/bitnami/apps/wordpress/conf/certs/server.key
sudo chmod 600 /opt/bitnami/apps/wordpress/conf/certs/server.key

I also setfacl the /etc/ and /opt/ folder.

Those commands shouldn’t have changed permissions of the .ssh folder.

Can you tell what the permissions of the ~/.ssh folder are ? have you got another account you can ssh in with to be able to see ?

Let me check, but first this question.
GCE offers a variety of engines (VM)

  • Micro (1 shared vCPU, 0.6gb memory)
  • small (1 shared vCPU, 1.7GB)
  • 1 vCPU (3.75GB)
  • 2 vCPU (7.5GB)

As you just mentioned about permissions, could it be related to the fact the instance is installed on a shared vCPU?

No, it’s permissions of the files (which should not be shared), not the CPU.

I created another instance to be able to check the standard configurations of .ssh
This is set on 700.

In the ~/.ssh folder there is a file with a set of authorized keys which are Added by Google. SSH-rsa keys.