As the hosting operator, you choose whether your customers can manage their Lightsail firewall through the service’s Firewall tab. The client-area steps below show how an SSH rule is added. Opening a port changes network access; it does not create an SSH account, start an SSH service or replace the server’s login key.

Check the prerequisites

Enable Client: Firewall in the package’s module options for the service you intend to expose this control on. Check that the affected service shows the Firewall tab. Your customer follows the steps below from that service in the Blesta client area. Confirm the current server address and SSH username through Connection details.

Use the port on which your server actually runs SSH. Port 22 is the usual starting point, but a customised server can use another port. Decide which source address or trusted network should be allowed.

Customer steps: add the SSH rule

1. Open the service’s Firewall tab and review its existing rules before adding another.
2. Choose the control to add a rule and select TCP.
3. Set both ends of the port range to your SSH port, for example 22 for a standard configuration.
4. Enter the allowed source IP address or CIDR range. Prefer the address or trusted network that needs access rather than opening management access to everybody.
5. Save the rule and confirm that the protocol, ports and source range appear correctly in the list.
6. Try a fresh SSH connection using the service’s current address, username and private key.

A blank source allows any IPv4 address. IPv6 rules have their own source range; ::/0 allows every IPv6 address. Use those broad ranges only when they match your intended access policy.

Change or remove a rule

To change a rule, remove it and add the intended replacement. Keep another working access method available while changing management access. If your network’s public IP changes, an old single-address rule will no longer match your new connection.

Remove rules you no longer need after checking that the intended access still works. Avoid removing web or application ports just because they are unrelated to SSH.

If SSH still fails

A timeout can mean a wrong address, a source range that does not match your connection, another firewall on the server or an SSH service that is not listening. A permission-denied response normally means the connection reached SSH but the username or key needs checking. Follow the direct SSH guide for those login checks.

If your customer cannot see Firewall, check Client: Firewall in the package’s module options and the affected service’s controls. If the rule saves correctly but SSH still fails, continue your hosting-team checks of the address, source range, server firewall and SSH login; a saved rule alone does not establish that the application is reachable.

See the PD AWS Lightsail Blesta guide for related tasks, or explore the module.