Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

Share this Page URL

Allowing SSH Connections > Using sshd_config Options - Pg. 270

270 Chapter12·SSHServerAdvancedUse With TCP Wrappers' limited functionality and syntax, you might wonder why you would ever use it over simply using netfilter. Because iptables works at the packet level, if you want to deny access to a particular process, such as HTTP, you must do it based on port number. Thus, if you use netfilter to explicitly block connection attempts to port 80, and the user starts up the Web server and tells it to listen on port 8080, the connection will be allowed. With TCP Wrappers, you permit or deny access to a process instead of a port. In this way, you can ensure that a given process will work regardless of the port it is using. This distinction could prove invaluable if you have a service that uses a large number of listening ports. Some services want you to open up a very large range of ports, rendering your local firewall nearly useless. Some services use an incrementing port with each instance that is spawned, again requiring a large range of ports to be opened. Finally, perhaps an even more common scenario that renders packet level port filtering useless is when the session is tunneled within another protocol. For example, if you are tunneling FTP within SSH, a packet filter will see it as port 22 encrypted traffic, but TCP Wrapper can see it as ftpd and block based on the hosts.allow and hosts.deny files accordingly. T ip If the line is too long in the hosts.allow or hosts.deny file, you will generate an error. You must \ separate lines that wrap to the next line with a slash at the end of the line to prevent an \ error from occurring. Using sshd_config Options The /etc/ssh/sshd_config file is the key mechanism for controlling how the SSH daemon behaves. The configuration file has several options that can be used to restrict who has access to the sshd process. The most applicable options include the AllowGroups, AllowUsers, DenyGroups, and DenyUsers keywords. These keywords accept user or group names and pretty much do exactly what it sounds like they would. The keywords are processed in the following order: DenyUsers, AllowUsers, DenyGroups, and AllowGroups, regardless of the order in which they appear inside the sshd_config file. This means the more granular user-based permissions override the group-based permissions. The sshd_config file lists default values for various options, but they are all commented out. To change a value from the default, you must first uncomment a line and then configure the desired value. The AllowUsers and other options in which we are interested are not listed in the configuration file by default and must be added. To permit connections from the users "test" and "test1," you would add the following anywhere in the /etc/ssh/sshd_config file: AllowUsers test test1 Multiple entries for these keywords are all made on one line with a space between values. After making changes to the sshd_conf file, you will need to restart the sshd process for them to take effect. This can be done by entering: