Click on the Networking icon on the module's main page to bring up the form shown in Figure 42.2.

By default, the server will accept connections made to any of your system's IP addresses. To change this (perhaps because you want it to be only accessible from an internal LAN), select the second radio button in the Listen on address field and enter an IP address into the text box.

If you are running OpenSSH, version 3 or above, this field will instead contain a table in which you can enter multiple addresses and ports. Above it are two radio buttons: All addresses, which if selected tells the server to accept connections to the default port on any IP address, and Entered below, which indicates that the addresses and ports in the table should be used. As is usual with tables in Webmin, this one will always have a single blank row at the bottom for adding a new address and port. If none have been defined yet, it will only contain one blank row. The meanings of the fields in the table's two columns are:

Address In this field you must enter a single IP address or hostname on which the server is listed.

Port If Default is selected in this column, the standard port set in Step 3 will be used. If the second option is selected, the SSH server will listen on the port entered into the text box in the column.

To change the port on which the SSH server listens for connections, edit the Listen on port field. If you do change it, clients will need to specify the new port when connecting. If your system uses OpenSSH version 3 or above, this field only sets the default port, which can be overridden in the Listen on address table.

In the Accept protocols field, check the boxes for the SSH protocol versions that your server should accept. It is generally wise to allow both, so older or newer clients can connect without difficulty. This field only appears if you are running OpenSSH; however, SSH accepts only version 1 or 2 depending on the SSH version you have installed.

If you are running SSH, the Idle timeout field can be used to disconnect clients that have neither sent or received any data for a certain amount of time. Select the second radio button, enter a period of time into the text box, and select the units for that period from the menu. If Default is selected, clients will never be cut off no matter how long they are idle. On a busy system, this feature can be useful for stopping people from leaving idle SSH sessions open for days at a time, each of which has an associated memory-consuming sshd and shell process.

To set the SSH server to disconnect clients that shut down or crashed without properly logging out, select Yes in the Disconnect if client has crashed? field. The server will periodically send messages to the client to make sure it is still really running, and close the connection if there is no reply. The only time you would want to choose No is if this extra traffic causes problems on your network, such as the automatic activation of an ISDN or dial-up connection when it is not really necessary.

To configure the amount of time that the server will wait for a client to authenticate after it has connected, change the Time to wait for login field. If Forever is chosen, the server will never disconnect a client no matter how long it takes, which could allow an attacker to overload your system by making lots of SSH connections that do nothing.

One of the SSH protocol's more interesting features is its support for port forwarding, which allows clients to access ports on the server's network that they could not ordinarily. Even though this is very useful for users, you might consider it a security risk as it allows anyone who can make an SSH effectively bypass IP address restrictions on internal servers. To turn off this feature, change the Allow TCP forwarding? field to No.

This field only appears if you are running SSH version 2 or above or OpenSSH.

A related field is Allow connection to forwarded ports?, which determines if hosts other than the server itself are allowed to connect to ports forwarded back to the client. You may want to set this to No to protect client users from attackers who are misusing possibly insecure forwarded connections back to the client's network. It only appears, however, if your system runs OpenSSH version 2 or above.

To have the server look up the hostnames for client addresses and the address for those hostnames, and then block those that do not match, select Yes in the Reverse-validate client IP addresses? field. This is useful if you have hostname-based access controls in place and want to detect attackers using falsified DNS records. This field is only visible if you are running OpenSSH version 2.3 or above.

To save and activate your changes, hit the Save button at the bottom of the page and then Apply Changes back on the module's main page. They will take effect for any new client connections.