Tuesday, June 30, 2015

SSH stuck on "expecting SSH2_MSG_KEX_ECDH_REPLY" && using openconnect VPN

Just built a brand new virtual deskop using Vagrant & Puppet to automate the install of a CentOS virtual desktop.  My goal is to build automation into the project from the ground up - the only way to truly do this is to scrap and rebuild many times yet I was having a big issue w/ a fundamental requirement.

I needed openconnect installed to VPN into multiple infrastructure nodes.  Unfortunately, I wasn't able to connect to other infrastructure servers (via ssh) and the system was responding w/ a timing out exception.

To gain a better view I enabled verbose ssh output using the "-vvv" parameter and quickly saw the system was stuck at the  "expecting SSH2_MSG_KEX_ECDH_REPLY" phase.

I was fortunate to have a working VM and performed multiple compare & contrasts against settings.  With debugging enabled I was able to see the server was sending a host key over to the client.  On the broken system it was not receiving that key...

After performing a ton of research to resolve the issue I found many mixed results from individuals.  Seems there are a mix of server (router, sshd, etc) and client side configurations that could be changed to optimize the maximum transmission unit value.

Seems lowering the MTU value in the systems: /etc/sysconfig/network-scripts/ifcfg-enp0s3 worked. 

It was timing out @ 1500 yet worked @ 1200

Reference Link

http://www.microhowto.info/howto/persistently_change_the_mtu_of_a_network_interface_on_redhat.html

 New Settings

bash-4.2$ cat /etc/sysconfig/network-scripts/ifcfg-enp0s3
TYPE=Ethernet
BOOTPROTO=dhcp
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=enp0s3
UUID=78140972-c1ee-4220-85af-b67ff1bc3cad
DEVICE=enp0s3
ONBOOT=yes
MTU=1200

No comments: