Question

SSH with FreeBSD and cloud firewall

Hi all, I have a cloud firewall that allows SSH from all IPv4 and all IPv6 addresses on port 22. It is applied to all droplets with the tag “ssh”. If I create a droplet from the freebsd-12-x64-zfs image in the cloud with the SSH tag and wait for it to boot (verified using the console), I sometimes can’t SSH into the machine (the connection hangs trying to connect).

This happens consistently if I build the machine with Packer, and was happening consistently with just this image (it worked with other images) if I built it from the control panel (new droplet, select FreeBSD, select basic s-1vcpu-1gb option, select NYC3, all SSH keys, add tag ssh, hit create) yesterday, but today it seems to be fine if I go that route.

Since you can’t change the root password on FreeBSD images using the control panel I’ve been unable to run anything on these machines to try and figure out what’s going on, and contacting support has been useless because I just cannot convince them that I can’t run commands (literally every email back and forth I try to explain that I can’t run anything, then they say “okay, in that case run these other commands on the new droplet instead”). Does anyone have any ideas?

Other images seem to work (though I haven’t tried them with the packer method, so it may be that they would fail in the same way when using packer), and the same thing happens if I change the region. It does not happen if I manually apply the firewall (instead of relying on the tags) as far as I can tell, but I can’t do that from packer. At least once I’ve seen it suddenly start working after ~10 minutes and several reconnect attempts, but normally I just get this if I try to ssh in:

$ ssh -vv root@137.184.17.223
OpenSSH_8.7p1, OpenSSL 1.1.1l  FIPS 24 Aug 2021
debug1: Reading configuration data /home/sam/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug2: checking match for 'final all' host 137.184.17.223 originally 137.184.17.223
debug2: match not found
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: configuration requests final Match pass
debug2: resolve_canonicalize: hostname 137.184.17.223 is address
debug1: re-parsing configuration
debug1: Reading configuration data /home/sam/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug2: checking match for 'final all' host 137.184.17.223 originally 137.184.17.223
debug2: match found
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: Connecting to 137.184.17.223 [137.184.17.223] port 22.
<hangs here until it times out>

EDIT: tried a different (Fedora) image with Packer and it can’t be SSHed into as well even though I can verify in the console that the firewall is applied that allows SSH. Maybe it was just a coincidence that they were working yesterday from the console while FreeBSD was not and that everything appears to be working from the console today.

Show comments

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.

Hi there,

Is this also the case for a Droplet that is not protected by the Cloud firewall in question?

As this was working the day before, are you by any chance connected to a VPN that could be blocking any outgoing traffic on port 22?

Usually, to quickly test if it could be related to your local network configuration, you could use the portquiz.net website and run the following:

telnet portquiz.net 22 

If the connection fails, then it indicates that your local network might be causing the issue.

Best,

Bobby