Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
You’re not running your sshd daemon on port 80 or 443 are you (those are very non-standard for SSH but could be used to get around certain proxy configurations)? That’s the only way I could see certbot having any effect on your ssh server.
I don’t have any problem with ssl itself, but it seem that port 22 got blocked after using certbot, I check iptables and ssh port are allowed, I don’t know what happen after reboot that I can’t login to server and I get “network error network error connection refused”
The only things certbot changes are within /etc/letsencrypt/ or nginx/Apache configuration files (but only when the nginx or apache plugin is used).
I won’t say it’s fully impossiblecertbot couldn’t result in SSH issues, but it’s very, very improbably, next to impossible certbot is responsible for SSH not being reachable.
I know it’s sound silly, but this happend for me, I tried three times by reinstalling my server , after that installing certbot and check iptables , every thing work and ssh port was open, but after reboot SSH fails. I don’t know it’s possible that old kernel cause this? because server use openvz6
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving “poorya.me” port ***
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to poorya.me [*******] port ***.
debug1: connect to address ******* port ***: Connection refused
ssh: connect to host poorya.me port ***: Connection refused
Unfortunately my provider doesn’t provide web console so I can’t use that to access my server
Connection refused just means that nobody is listening on that port.
So either OpenSSH has stopped running on the server, or it is listening on a different port.
If you can’t get a web console, then you pretty much will need to get your provider to enter your container from the host, and check what’s happening themselves.