From Fedora Project Wiki
(Created page with "{{QA/Test_Case |description=A brief description of the functionality being tested. |setup=Optionally include information on preparing the test environment |actions= Be as spec...")
 
(First test case formalised)
Line 1: Line 1:
{{QA/Test_Case
{{QA/Test_Case
|description=A brief description of the functionality being tested.
|description=Verify that OpenSSH works without tcp_wrappers and is not affected by its configuration by default
|setup=Optionally include information on preparing the test environment
|setup=Make sure OpenSSH packages (client and server) are installed. Check that tcp_wrappers package is installed:
 
<code>rpm -q openssh-server openssh-clients tcp_wrappers</code>
|actions=
|actions=
Be as specific as required for the target audience.  
# Check openssh server is NOT linked against libwrap: <code><nowiki>ldd /usr/sbin/sshd |grep libwrap</nowiki></code>
# Start here ...
# Make sure there is no allowing rule in <code>/etc/hosts.allow</code> (the file contains only commented-out lines)
# Next do this ...
# Insert the following blocking rule in the <code>/etc/hosts.deny</code>: <code>sshd: localhost</code>
# Finally click that
# Attempt to connect to localhost using ssh: <code>ssh localhost</code>
# Configure the socket-activated sshd service with <code>tcpd</code> as described in the [[Changes/Deprecate_TCP_wrappers#Migration_to_tcpd|change page, section "Migration to tcpd"]].
# Verify, that the connection is rejected with the configuration from step 3:  <code>ssh localhost</code>
# Remove the blocking rule that we added in step 3 from <code>/etc/hosts.deny</code>
# Verify that you can connect successfully now:  <code>ssh localhost</code>
|results=
|results=
The following must be true to consider this a successful test run. Be brief ... but explicit.  
The following must be true to consider this a successful test run. Be brief ... but explicit.  
# Step #1 completes without error
# Step #1 should not return anything
# The system boots into runlevel 5
# Step #3 completes successfully (there is either password prompt or you are allowed in by public key authentication)
# Program completes with exit code 0
# Step #6 should reject the connection.
|optional=Optionally provide hints for exploratory testing.
# Step #8 should connect successfully again (there is either password prompt or you are allowed in by public key authentication)
|optional=If you see some issues, investigate the logs in journal, make sure the services are running.
# If you have problems with <code>tcpd</code>, try to run with SELinux in permissive mode or look for update of <code>selinux-policy</code>. The bug [https://bugzilla.redhat.com/show_bug.cgi?id=1482554 #1482554] might not be fixed yet.
}}
}}

Revision as of 11:55, 16 March 2018

Description

Verify that OpenSSH works without tcp_wrappers and is not affected by its configuration by default

Setup

Make sure OpenSSH packages (client and server) are installed. Check that tcp_wrappers package is installed:

rpm -q openssh-server openssh-clients tcp_wrappers

How to test

  1. Check openssh server is NOT linked against libwrap: ldd /usr/sbin/sshd |grep libwrap
  2. Make sure there is no allowing rule in /etc/hosts.allow (the file contains only commented-out lines)
  3. Insert the following blocking rule in the /etc/hosts.deny: sshd: localhost
  4. Attempt to connect to localhost using ssh: ssh localhost
  5. Configure the socket-activated sshd service with tcpd as described in the change page, section "Migration to tcpd".
  6. Verify, that the connection is rejected with the configuration from step 3: ssh localhost
  7. Remove the blocking rule that we added in step 3 from /etc/hosts.deny
  8. Verify that you can connect successfully now: ssh localhost

Expected Results

The following must be true to consider this a successful test run. Be brief ... but explicit.

  1. Step #1 should not return anything
  2. Step #3 completes successfully (there is either password prompt or you are allowed in by public key authentication)
  3. Step #6 should reject the connection.
  4. Step #8 should connect successfully again (there is either password prompt or you are allowed in by public key authentication)

Optional

If you see some issues, investigate the logs in journal, make sure the services are running.

  1. If you have problems with tcpd, try to run with SELinux in permissive mode or look for update of selinux-policy. The bug #1482554 might not be fixed yet.