Red Hat Enterprise Linux Diagnostics and Troubleshooting

Re-create the issue.

1. Log in to servera and switch to the root user.

   [student@workstation ~]$ ssh student@servera
   ...output omitted...
   [student@servera ~]$ sudo -i
   [sudo] password for student: student
   [root@servera ~]#

2. Use the ssh command to perform a remote command on the serverb system as the student user. Note the time that it takes to connect. When prompted, provide student as the password.

   A small delay occurs before the connection is established.

   [root@servera ~]# ssh student@serverb echo hello
   ...delay...
   The authenticity of host 'serverb (172.25.250.11)' can't be established.
   ECDSA key fingerprint is SHA256:NJAyJMx8B2AeIYHRnVLAuJ1XZwblomyOKowyfTwGrTY.
   Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
   Warning: Permanently added 'serverb,172.25.250.11' (ECDSA) to the list of known hosts.
   student@serverb's password: student
   hello

Gather information.

1. Use strace to run the ssh command to discover whether the command stalls at a specific point.

   The output pauses on a specific connect system call.

   [root@servera ~]# strace ssh student@serverb echo hello
   ...output omitted...

   This system call, and the subsequent getsockname call, show a failed attempt to connect to an IPv6 socket on the serverb system. When these attempts fail, an IPv4 socket is successfully opened.

   connect(5, {sa_family=AF_INET6, sin6_port=htons(22), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "fd37:5265:6448:6174::b", &sin6_addr), sin6_scope_id=0}, 28

2. Inspect the IP addresses of the serverb system.

   The IPv6 address on the eth1 interface is correctly configured. Because the IPv4 protocol succesfully connects, it is likely that a rule is preventing IPv6 traffic from reaching serverb.

   [root@servera ~]# ssh student@serverb ip addr
   student@serverb's password: student
   1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
       link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
       inet 127.0.0.1/8 scope host lo
          valid_lft forever preferred_lft forever
       inet6 ::1/128 scope host
          valid_lft forever preferred_lft forever
   2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
       link/ether 52:54:00:00:fa:0b brd ff:ff:ff:ff:ff:ff
       inet 172.25.250.11/24 brd 172.25.250.255 scope global noprefixroute eth0
          valid_lft forever preferred_lft forever
       inet6 fe80::6dab:7b1:80c9:4f7f/64 scope link noprefixroute
          valid_lft forever preferred_lft forever
   3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8942 qdisc fq_codel state UP group default qlen 1000
       link/ether 52:54:00:01:fa:0b brd ff:ff:ff:ff:ff:ff
       inet6 fd37:5265:6448:6174::b/64 scope global noprefixroute
          valid_lft forever preferred_lft forever
       inet6 fe80::a969:1f7e:a542:51b2/64 scope link noprefixroute
          valid_lft forever preferred_lft forever

Fix and then verify that the issue is resolved.

1. From the workstation system, open a new terminal. Log in to serverb and switch to the root user.

   [student@workstation ~]$ ssh student@serverb
   ...output omitted...
   [student@serverb ~]$ sudo -i
   [sudo] password for student: student
   [root@serverb ~]#

2. Inspect the firewall rules.

   A rich rule is denying all incoming IPv6 traffic.

   [root@serverb ~]# firewall-cmd --list-all
   public (active)
     target: default
     icmp-block-inversion: no
     interfaces: eth0 eth1
     sources:
     services: cockpit dhcpv6-client http ssh
     ports:
     protocols:
     masquerade: no
     forward-ports:
     source-ports:
     icmp-blocks:
     rich rules:
   	rule family="ipv6" source address="0::0/0" reject

3. Remove the unwanted rule and reload the firewall.

   [root@serverb ~]# firewall-cmd --permanent --remove-rich-rule='rule family="ipv6" source address="0::0/0" reject'
   [root@serverb ~]# firewall-cmd --reload

4. From the terminal that is connected to servera, attempt the ssh command again. Verify that the delay no longer occurs.

   [root@servera ~]# ssh student@serverb echo hello
   ...output omitted...

5. Close the additional terminal to serverb and return to workstation as the student user.

   [root@serverb ~]# exit
   [student@serverb ~]$ exit
   [student@workstation ~]$ exit

   [root@servera ~]# exit
   [student@servera ~]$ exit
   [student@workstation ~]$