How do I make the ssh daemon available?

[whitwye]

Since the guided installation from USB to HD failed when running it from a shell in a iDRAC session, I'm now trying to use SSH. The manual says:

The GUI will listen on https://192.168.1.1/ for user “root” with password “opnsense”. Using SSH, the “root” and “installer” users are available as well on IP 192.168.1.1. Note that these install medias are read-only, which means your current live configuration will be lost after reboot.

In this case I've installed the LAN interface at 172.17.10.3. The web version is available. SSH is not.  When I try to ssh to localhost there is a daemon there. And telneting to port 22 on localhost shows it's the standard OpenSSH. But from another system, that can reach the HTTPS interface for 172.17.10.3, I can't reach the SSH daemon.

[whitwye]

Checking the firewall for the LAN interface through the web dashboard, I see there's no rule to allow SSH. I try to add one from any TCP4 to the SSH port. It saves it however as from any TCP4 to any port. I can try several more times. It won't save it as just for SSH. What does it take to get the target port specification to stick?

Anyway, even at any-to-any port, I still can't connect to SSH.

[whitwye]

Okay, wasn't looking closely enough at the "From:" and "To:" -- that it wants a range, not just a To: port. My mistake there.

Still, it would be good if the doc mentioned that SSH is not available prior to altering the firewall; or if the firewall default allowed SSH.

[fabian]

Still, it would be good if the doc mentioned that SSH is not available prior to altering the firewall; or if the firewall default allowed SSH.

If the anti lockout rule is acitive, it includes SSH.

[whitwye]

Fabian,

With respect, the anti-lockout rule is there, and specifies only ports 443 and 80. It does not include port 22. (pfSense does include port 22 in that rule.)

Now that we've got the Dell hardware trouble quieted down with upgraded firmware, and have booted OPNsense from its hard drives, I find no ssh daemon running. I can no longer even connect with "ssh localhost" from an iDRAC console session.

I've looked through the menus and the manual for where the switch might be to be sure the ssh daemon is always brought up. Haven't found that yet.

Best,
Whit

[fabian]

The anti lockout includes the configured SSH port:
https://github.com/opnsense/core/blob/511cdd471e6c90ab5ecbbd5d5125adb0b906601f/src/etc/inc/filter.lib.inc#L49-L67

[whitwye]

Hi Fabian,

We installed from the VGA USB file, which we downloaded fresh yesterday. It did not have port 22 included in anti-lockout. I can't speak to "the configured ssh port," but 22 is the default and it did not ask us to choose one to configure for it. Is the VGA USB file a buggy version in this regard?

Now I have had to manually invoke /usr/local/sbin/sshd to get sshd running at all. Somehow the automation has failed. I see from the files that on a normal FreeBSD system that should be flagged to start in /etc/rc.conf (that's what /usr/local/etc/rc.d/openssh says still in OPNsense). Of course you're not using rc.conf. What should I adjust to be sure sshd is started at boot?

I appreciate all the work you've put into this. My frustrations today have been more with Dell. Still, I hope the goal is to have ssh, in particular, be dependably available.

Thanks,
Whit

[whitwye]

Hi Fabian,

Looking at your code:

        if (isset($config['system']['ssh']['enabled'])) {
            $lockout_ports[] = empty($config['system']['ssh']['port']) ? "22" : $config['system']['ssh']['port'];
        }

Where, please, is ssh enabled and disabled? I have never knowingly taken action to disable it; nor have I seen the option to do either. The docs simply say that it will be available. The bug here appears not to be in that code, but somewhere else, resulting in ssh not being enabled when it should be.

Note that in starting from the USB stick the ssh daemon is running, but port 22 is not included in anti-lockout. Starting from the hard drive, after installing from USB, sshd isn't even running.

Whit

[whitwye]

Okay, found it under System > Administration.

That still leaves as a bug that in running from the VGA USB version of the distribution, sshd is running, but the firewall won't let it in without a rule adjustment.

Also, as a feature request, the default should be for it to install with ssh enabled, at least on the LAN interface. Either that, or document that it won't be.

Best,
Whit

[franco]

SSH defaults to prevent root login and password login. Even if we enable it by default, you can't use it without going to the GUI. For that reason, the fact that we only have a root account and a default password (somewhat changed since the 17.7 installer) it would be insecure to simply run ssh, permit root and password login by default.

Either that, or document that it won't be.

Isn't that documented by not being written down? Why the extra work that very few people are going to even read and will likely not find useful if they do?

That still leaves as a bug that in running from the VGA USB version of the distribution, sshd is running, but the firewall won't let it in without a rule adjustment.

Please explain how to reproduce this.


Cheers,
Franco

[whitwye]

That still leaves as a bug that in running from the VGA USB version of the distribution, sshd is running, but the firewall won't let it in without a rule adjustment.

Please explain how to reproduce this.

Hi Franco,

You're in luck. I'm repeating the installation on the same system, since I want to be sure everything is consonant with the upgraded firmware that was required on the Dell. So:

1. Boot from "VGA" "amd64" USB version.

2. Go into section to manually set interfaces; set only LAN interface (probably unnecessary to replicate, but necessary in my shop).

3. Go to option 2 on OPNsense CLI menu and set the LAN IP address and gateway.

4. (Optional) Drop to shell from menu and verify that sshd is running with "ssh localhost".

5. Connect to web dashboard from another system.

6. (Optional) Confirm that ssh connection is not available from the same other system.

7. In web dashboard go to FIrewall > Rules > LAN.

8. Look at Anti-Lockout Rule, which will have only ports 443 and 80.

9. Read doc, which says (in error) that ssh access should be available at this point.

10. Add new rule for LAN through web interface, allowing port 22 access to firewall from any (or a more restricted range).

11. Try again from same system as is connecting for web dashboard.

12. It now works!

Best,
Whit

[franco]

Alright, you found the case where this breaks, which was never reported before, but I added a ticket recently to keep this on the roadmap for 18.1.

https://github.com/opnsense/core/issues/1750

If you have a WAN and a LAN, it will work because LAN access is unrestricted by default. Any WAN will do, even if defunct.

If there is only a LAN or WAN, it will try to lock down and miss the fact that SSH is required (the subsystems are not related). There are other side effects here when I try this so that will certainly be improved. Thanks for the pointers.


Cheers,
Franco

[whitwye]

When you say "any WAN will do," guess that doesn't include the stub of one that's there even if one has not been wired up yet.

Available interfaces:

1 - LAN (igb0 - static)
2 - WAN (igb1 - dhcp, dhcp6)

Or is it the order that's determinative here, and the default of putting the WAN first?

Thanks for adding this to the todo list.

[franco]

When the automatic assignment runs, let it run automatically and then reconfigure or assign both a WAN and LAN there. This step is currently crucial to have SSH up and running and accessible freely from LAN. You can change the WAN / LAN IP assignment afterwards.

The ticket mentioned was closed just now, seems to work after multiple commits/consolidation efforts. I don't know yet if there will be any images for a 17.7.x, right now this change is in the queue for 18.1.


Cheers,
Franco