You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@guacamole.apache.org by ha...@faa.gov on 2018/01/22 14:02:52 UTC
Connection failures
Today, when I try to connect to any connection we have in Guacamole (0.9.13), either an SSH or RDP connection, I get the following error:
[cid:image001.png@01D3935F.C7CA0C80]
I tried to look in the logs under /var/log/tomcat but didn't see anything about any errors. What logs should I be looking at to find out what could be going on and fix this? We are hoping to roll our Guacamole implementation out to more users very soon, and we can't have this type of erroring happening without knowing why and how to fix it.
Thanks,
Harry
Harry Devine
DOT/FAA/AJM-2412
Common ARTS Software Development
Terminal Server (NASDAC) Adminstrator
Red Hat Certfied System Adminstrator (RHCSA)
harry.devine@faa.gov<ma...@faa.gov>
(609)485-4218
Building 300, 3rd Floor, Column L20 (3L20)
RE: Connection failures
Posted by ha...@faa.gov.
I just played around with my setup for an RDP connection we have, and what you suggested didn't work. The RDP server is a Windows 2008 R2 server. I truly believe that the issue is due to us making our machines FIPS compliant, which is why SSH connections now fail with "SSH handshake failed". However, we didn't make any changes at all to our Windows servers, so I would've expected the RDP connections to work as they always had, which is not the case.
Also, someone else had mentioned that the problem was antivirus and to turn that off. First of all, that's not the issue, as I get the connection failures for both SSH and RDP when I use a browser on a Linux box. Secondly, I can't turn off our antivirus as its controlled by our IT department and we don't have admin rights to be able to do that.
I am assuming that Guacamole is using an SSH library that is NOT FIPS-140 compliant? If so, are there updates that need to be installed to allow this? Even via a guacamole recompile?
Thanks for the help!
Harry
-----Original Message-----
From: ldap123user [mailto:kontokala7@gmail.com]
Sent: Wednesday, January 24, 2018 6:34 AM
To: user@guacamole.apache.org
Subject: RE: Connection failures
I had same error over RDP. Problem is to set ignore certificates and use NLA authentication (windows 2012 R2) This settings helped me connect with
success:
<connection name="Windows">
<protocol>rdp</protocol>
192.168.0.2
3389
test
password
nla
true
true
</connection>
--
Sent from: http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/
RE: Connection failures
Posted by ldap123user <ko...@gmail.com>.
I had same error over RDP. Problem is to set ignore certificates and use NLA
authentication (windows 2012 R2) This settings helped me connect with
success:
<connection name="Windows">
<protocol>rdp</protocol>
192.168.0.2
3389
test
password
nla
true
true
</connection>
--
Sent from: http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/
Re: Connection failures
Posted by Nick Couchman <vn...@apache.org>.
On Tue, Feb 6, 2018 at 1:18 PM, <ha...@faa.gov> wrote:
> I checked with Red Hat, and their latest released version is 1.4.3. They
> made it seem like they are not currently going to release anything newer,
> but I’m trying to get them to give me a time frame. We can’t SSH to FIPS
> 140-2 compliant machines via guacamole without it. When I get
> libssh2-devel resolved/updated, would I have to recompile guacamole?
>
>
>
I highly doubt that Red Hat is going to bump up the version of libssh2 any
time before RHEL 8 is released - for major releases they do not have a
habit of making jumps in versions. libssh2 should be relatively easy to
compile yourself, though, if you so choose - I don't imagine there are all
that many requirements for it, so it's probably as simple as ./configure &&
make && make install.
-Nick
RE: Connection failures
Posted by Mike Jumper <mi...@guac-dev.org>.
I believe you should be able to just update the library and have things
work, without recompiling Guacamole. The libssh2 project is pretty good
about not breaking the API or ABI. Just make sure that the older version is
fully uninstalled, and once the new version is installed maybe double-check
using ldd that libguac-client-ssh.so still links against libssh2.
- Mike
On Feb 6, 2018 10:19, <ha...@faa.gov> wrote:
> I checked with Red Hat, and their latest released version is 1.4.3. They
> made it seem like they are not currently going to release anything newer,
> but I’m trying to get them to give me a time frame. We can’t SSH to FIPS
> 140-2 compliant machines via guacamole without it. When I get
> libssh2-devel resolved/updated, would I have to recompile guacamole?
>
>
>
> Thanks,
>
> Harry
>
>
>
> *From:* Mike Jumper [mailto:mike.jumper@guac-dev.org]
> *Sent:* Wednesday, January 24, 2018 5:08 PM
> *To:* user@guacamole.apache.org
> *Subject:* Re: Connection failures
>
>
>
> On Wed, Jan 24, 2018 at 2:02 PM, Mike Jumper <mi...@guac-dev.org>
> wrote:
>
> On Wed, Jan 24, 2018 at 11:49 AM, <ha...@faa.gov> wrote:
>
> Did some more debugging. When we try to connect to a server that is FIPS
> 140-2 compliant, here’s what the algorithms that are expected are:
>
>
>
> When I try to connect via a Guacamole SSH session, here are the algorithms
> being sent:
>
> debug2: KEX algorithms: ecdh-sha2-nistp256,ecdh-sha2-n
> istp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha
> 256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha
> 512,diffie-hellman-group14-sha256,ext-info-c
>
> debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,
> ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-
> sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,
> ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com
> ,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-
> sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss
>
> debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-c
> tr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
>
> debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-c
> tr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
>
> debug2: MACs ctos: hmac-sha1,hmac-sha2-256,hmac-sha2-512,
> hmac-sha1-etm@openssh.com,hmac-sha2-256-etm@openssh.com,
> hmac-sha2-512-etm@openssh.com
>
> debug2: MACs stoc: hmac-sha1,hmac-sha2-256,hmac-sha2-512,
> hmac-sha1-etm@openssh.com,hmac-sha2-256-etm@openssh.com,
> hmac-sha2-512-etm@openssh.com
>
>
>
> Jan 24 14:42:38 carts sshd[6890]: FIPS mode initialized
>
> Jan 24 14:42:38 carts sshd[6890]: Unable to negotiate with 172.26.170.72
> port 57948: no matching key exchange method found. Their offer:
> diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
> [preauth]
>
>
>
> Looks like, to me, that Guacamole isn’t sending the proper algorithms or
> ciphers in its SSH request. Not sure if the issue is in Guacamole itself
> or in libssh2, which is 1.4.3 at the moment.
>
>
>
>
>
> The connection handshake for SSH connections (key exchange, ciphers, etc.)
> is actually dictated internally by libssh2, so that much is out of
> Guacamole's control. Checking the current libssh2 source, the key exchange
> methods reported as rejected above are the only key exchange methods
> supported by libssh2:
>
>
>
> https://github.com/libssh2/libssh2/blob/bcd492163b71608f8e46
> cdc864741d6c566ce9bc/src/kex.c#L1777-L1783
>
>
>
>
>
> Correction: the version of libssh2 which you are using, 1.4.3, lacks
> support for "diffie-hellman-group-exchange-sha256":
>
>
>
> https://github.com/libssh2/libssh2/blob/f1cfa55b6064ba18fc00
> 05713ed790da579361b5/src/kex.c#L939-L944
>
>
>
> It was added via:
>
>
>
> https://github.com/libssh2/libssh2/commit/fc4a969a0512e226de
> 9b821496d20b9ddf53b741
>
>
>
> which is apparently part of their 1.7.0 and 1.8.0 releases. I have not
> checked whether those version support the ciphers and MACs that your server
> requires, but updating to 1.7.0 or 1.8.0 should get you further in the
> process. What you're looking for is impossible to achieve with libssh2
> 1.4.3.
>
>
>
> - Mike
>
>
>
RE: Connection failures
Posted by ha...@faa.gov.
I checked with Red Hat, and their latest released version is 1.4.3. They made it seem like they are not currently going to release anything newer, but I’m trying to get them to give me a time frame. We can’t SSH to FIPS 140-2 compliant machines via guacamole without it. When I get libssh2-devel resolved/updated, would I have to recompile guacamole?
Thanks,
Harry
From: Mike Jumper [mailto:mike.jumper@guac-dev.org]
Sent: Wednesday, January 24, 2018 5:08 PM
To: user@guacamole.apache.org
Subject: Re: Connection failures
On Wed, Jan 24, 2018 at 2:02 PM, Mike Jumper <mi...@guac-dev.org>> wrote:
On Wed, Jan 24, 2018 at 11:49 AM, <ha...@faa.gov>> wrote:
Did some more debugging. When we try to connect to a server that is FIPS 140-2 compliant, here’s what the algorithms that are expected are:
When I try to connect via a Guacamole SSH session, here are the algorithms being sent:
debug2: KEX algorithms: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com<ma...@openssh.com>,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se<ma...@lysator.liu.se>
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se<ma...@lysator.liu.se>
debug2: MACs ctos: hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-sha1-etm@openssh.com<ma...@openssh.com>
debug2: MACs stoc: hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-sha1-etm@openssh.com<ma...@openssh.com>
Jan 24 14:42:38 carts sshd[6890]: FIPS mode initialized
Jan 24 14:42:38 carts sshd[6890]: Unable to negotiate with 172.26.170.72 port 57948: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth]
Looks like, to me, that Guacamole isn’t sending the proper algorithms or ciphers in its SSH request. Not sure if the issue is in Guacamole itself or in libssh2, which is 1.4.3 at the moment.
The connection handshake for SSH connections (key exchange, ciphers, etc.) is actually dictated internally by libssh2, so that much is out of Guacamole's control. Checking the current libssh2 source, the key exchange methods reported as rejected above are the only key exchange methods supported by libssh2:
https://github.com/libssh2/libssh2/blob/bcd492163b71608f8e46cdc864741d6c566ce9bc/src/kex.c#L1777-L1783
Correction: the version of libssh2 which you are using, 1.4.3, lacks support for "diffie-hellman-group-exchange-sha256":
https://github.com/libssh2/libssh2/blob/f1cfa55b6064ba18fc0005713ed790da579361b5/src/kex.c#L939-L944
It was added via:
https://github.com/libssh2/libssh2/commit/fc4a969a0512e226de9b821496d20b9ddf53b741
which is apparently part of their 1.7.0 and 1.8.0 releases. I have not checked whether those version support the ciphers and MACs that your server requires, but updating to 1.7.0 or 1.8.0 should get you further in the process. What you're looking for is impossible to achieve with libssh2 1.4.3.
- Mike
Re: Connection failures
Posted by Mike Jumper <mi...@guac-dev.org>.
On Wed, Jan 24, 2018 at 2:02 PM, Mike Jumper <mi...@guac-dev.org>
wrote:
> On Wed, Jan 24, 2018 at 11:49 AM, <ha...@faa.gov> wrote:
>
>> Did some more debugging. When we try to connect to a server that is FIPS
>> 140-2 compliant, here’s what the algorithms that are expected are:
>>
>>
>>
>> When I try to connect via a Guacamole SSH session, here are the
>> algorithms being sent:
>>
>> debug2: KEX algorithms: ecdh-sha2-nistp256,ecdh-sha2-n
>> istp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha
>> 256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha
>> 512,diffie-hellman-group14-sha256,ext-info-c
>>
>> debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,
>> ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-
>> sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,
>> ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com
>> ,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-
>> sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss
>>
>> debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-c
>> tr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
>>
>> debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-c
>> tr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
>>
>> debug2: MACs ctos: hmac-sha1,hmac-sha2-256,hmac-sha2-512,
>> hmac-sha1-etm@openssh.com,hmac-sha2-256-etm@openssh.com,
>> hmac-sha2-512-etm@openssh.com
>>
>> debug2: MACs stoc: hmac-sha1,hmac-sha2-256,hmac-sha2-512,
>> hmac-sha1-etm@openssh.com,hmac-sha2-256-etm@openssh.com,
>> hmac-sha2-512-etm@openssh.com
>>
>>
>>
>> Jan 24 14:42:38 carts sshd[6890]: FIPS mode initialized
>>
>> Jan 24 14:42:38 carts sshd[6890]: Unable to negotiate with 172.26.170.72
>> port 57948: no matching key exchange method found. Their offer:
>> diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
>> [preauth]
>>
>>
>>
>> Looks like, to me, that Guacamole isn’t sending the proper algorithms or
>> ciphers in its SSH request. Not sure if the issue is in Guacamole itself
>> or in libssh2, which is 1.4.3 at the moment.
>>
>>
>>
>
> The connection handshake for SSH connections (key exchange, ciphers, etc.)
> is actually dictated internally by libssh2, so that much is out of
> Guacamole's control. Checking the current libssh2 source, the key exchange
> methods reported as rejected above are the only key exchange methods
> supported by libssh2:
>
> https://github.com/libssh2/libssh2/blob/bcd492163b71608f8e46cdc864741d
> 6c566ce9bc/src/kex.c#L1777-L1783
>
>
Correction: the version of libssh2 which you are using, 1.4.3, lacks
support for "diffie-hellman-group-exchange-sha256":
https://github.com/libssh2/libssh2/blob/f1cfa55b6064ba18fc0005713ed790da579361b5/src/kex.c#L939-L944
It was added via:
https://github.com/libssh2/libssh2/commit/fc4a969a0512e226de9b821496d20b9ddf53b741
which is apparently part of their 1.7.0 and 1.8.0 releases. I have not
checked whether those version support the ciphers and MACs that your server
requires, but updating to 1.7.0 or 1.8.0 should get you further in the
process. What you're looking for is impossible to achieve with libssh2
1.4.3.
- Mike
Re: Connection failures
Posted by Mike Jumper <mi...@guac-dev.org>.
On Wed, Jan 24, 2018 at 11:49 AM, <ha...@faa.gov> wrote:
> Did some more debugging. When we try to connect to a server that is FIPS
> 140-2 compliant, here’s what the algorithms that are expected are:
>
>
>
> When I try to connect via a Guacamole SSH session, here are the algorithms
> being sent:
>
> debug2: KEX algorithms: ecdh-sha2-nistp256,ecdh-sha2-
> nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-
> sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-
> sha512,diffie-hellman-group14-sha256,ext-info-c
>
> debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,
> ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@
> openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,
> ssh-dss-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,
> ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss
>
> debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-
> ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
>
> debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-
> ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
>
> debug2: MACs ctos: hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-sha1-etm@
> openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com
>
> debug2: MACs stoc: hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-sha1-etm@
> openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com
>
>
>
> Jan 24 14:42:38 carts sshd[6890]: FIPS mode initialized
>
> Jan 24 14:42:38 carts sshd[6890]: Unable to negotiate with 172.26.170.72
> port 57948: no matching key exchange method found. Their offer:
> diffie-hellman-group14-sha1,diffie-hellman-group-exchange-
> sha1,diffie-hellman-group1-sha1 [preauth]
>
>
>
> Looks like, to me, that Guacamole isn’t sending the proper algorithms or
> ciphers in its SSH request. Not sure if the issue is in Guacamole itself
> or in libssh2, which is 1.4.3 at the moment.
>
>
>
The connection handshake for SSH connections (key exchange, ciphers, etc.)
is actually dictated internally by libssh2, so that much is out of
Guacamole's control. Checking the current libssh2 source, the key exchange
methods reported as rejected above are the only key exchange methods
supported by libssh2:
https://github.com/libssh2/libssh2/blob/bcd492163b71608f8e46cdc864741d6c566ce9bc/src/kex.c#L1777-L1783
and the feature list on https://www.libssh2.org/ matches this:
>
> Capabilities and Features
>
> * Key Exchange Methods: diffie-hellman-group1-sha1,
diffie-hellman-group14-sha1, diffie-hellman-group-exchange-sha1,
diffie-hellman-group-exchange-sha256
> * ...
>
If these methods truly are not compliant with FIPS 140-2, then adding that
support to libssh2 would be the only possibility. If they are acceptable
within FIPS 140-2, then the SSH server likely needs to be configured to
allow them. Googling around, I've not yet found documentation explicitly
stating that these key exchange methods are non-compliant, though I see
several security policy PDFs for implementing FIPS 140-2 compliance
including a subset of these in their allowed key exchange methods.
Is there anything you could point to which explicitly lists what's
allowed/disallowed in your case?
- Mike
RE: Connection failures
Posted by ha...@faa.gov.
Did some more debugging. When we try to connect to a server that is FIPS 140-2 compliant, here’s what the algorithms that are expected are:
When I try to connect via a Guacamole SSH session, here are the algorithms being sent:
debug2: KEX algorithms: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: MACs ctos: hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-sha1-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com
debug2: MACs stoc: hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-sha1-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com
Jan 24 14:42:38 carts sshd[6890]: FIPS mode initialized
Jan 24 14:42:38 carts sshd[6890]: Unable to negotiate with 172.26.170.72 port 57948: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth]
Looks like, to me, that Guacamole isn’t sending the proper algorithms or ciphers in its SSH request. Not sure if the issue is in Guacamole itself or in libssh2, which is 1.4.3 at the moment.
Thanks,
Harry
From: Devine, Harry (FAA)
Sent: Wednesday, January 24, 2018 1:04 PM
To: user@guacamole.apache.org
Subject: RE: Connection failures
We had a fully patched RHEL 7.4 server, and ran the following commands on it (based on the article found here, which requires a Red Hat account to look at: https://access.redhat.com/solutions/137833 ):
yum install dracut-fips
grep -qw aes /proc/cpuinfo && echo YES || echo no
# If the above grep returns YES: yum install dracut-fips-aesni
rpm -q prelink
mv -v /boot/initramfs-$(uname -r).img{,.bak}
dracut
grubby --update-kernel=$(grubby --default-kernel) --args=fips=1
uuid=$(findmnt -no uuid /boot)
echo $uuid
[[ -n $uuid ]] && grubby --update-kernel=$(grubby --default-kernel) --args=boot=UUID=${uuid}
reboot
sysctl crypto.fips_enabled
sed -i '/^GRUB_CMDLINE_LINUX=/s/"$/ fips=1"/' /etc/default/grub
uuid=$(findmnt -no uuid /boot)
echo $uuid
[[ -n $uuid ]] && sed -i "/^GRUB_CMDLINE_LINUX=/s/\"$/ boot=UUID=${uuid}\"/" /etc/default/grub
reboot
Thanks,
Harry
From: Nick Couchman [mailto:vnick@apache.org]
Sent: Wednesday, January 24, 2018 11:54 AM
To: user@guacamole.apache.org<ma...@guacamole.apache.org>
Subject: Re: Connection failures
On Wed, Jan 24, 2018 at 10:55 AM, <ha...@faa.gov>> wrote:
As a test, I made a new Guacamole connection to a server that we did NOT make FIPS 140-2 compliant yet, and was able to get right in. So the FIPS 140-2 is definitely the issue. So I need to know if there’s something in guacamole 0.9.13 that I need to tweak, or libssh2. I’m not sure if I can update libssh2 to a newer version, as 1.4.3 is the latest available in the RHEL 7.4 patch trail.
Can you remind/post the changes made to make the SSH server FIPS 140-2 compliant? You may have already posted it, so apologies if that's a repeat, but I can try to reproduce and see what happens.
I do not believe there is anything in Guacamole specifically that deals with this, it should all be in libssh2, but we can take a look.
-Nick
RE: Connection failures
Posted by ha...@faa.gov.
We had a fully patched RHEL 7.4 server, and ran the following commands on it (based on the article found here, which requires a Red Hat account to look at: https://access.redhat.com/solutions/137833 ):
yum install dracut-fips
grep -qw aes /proc/cpuinfo && echo YES || echo no
# If the above grep returns YES: yum install dracut-fips-aesni
rpm -q prelink
mv -v /boot/initramfs-$(uname -r).img{,.bak}
dracut
grubby --update-kernel=$(grubby --default-kernel) --args=fips=1
uuid=$(findmnt -no uuid /boot)
echo $uuid
[[ -n $uuid ]] && grubby --update-kernel=$(grubby --default-kernel) --args=boot=UUID=${uuid}
reboot
sysctl crypto.fips_enabled
sed -i '/^GRUB_CMDLINE_LINUX=/s/"$/ fips=1"/' /etc/default/grub
uuid=$(findmnt -no uuid /boot)
echo $uuid
[[ -n $uuid ]] && sed -i "/^GRUB_CMDLINE_LINUX=/s/\"$/ boot=UUID=${uuid}\"/" /etc/default/grub
reboot
Thanks,
Harry
From: Nick Couchman [mailto:vnick@apache.org]
Sent: Wednesday, January 24, 2018 11:54 AM
To: user@guacamole.apache.org
Subject: Re: Connection failures
On Wed, Jan 24, 2018 at 10:55 AM, <ha...@faa.gov>> wrote:
As a test, I made a new Guacamole connection to a server that we did NOT make FIPS 140-2 compliant yet, and was able to get right in. So the FIPS 140-2 is definitely the issue. So I need to know if there’s something in guacamole 0.9.13 that I need to tweak, or libssh2. I’m not sure if I can update libssh2 to a newer version, as 1.4.3 is the latest available in the RHEL 7.4 patch trail.
Can you remind/post the changes made to make the SSH server FIPS 140-2 compliant? You may have already posted it, so apologies if that's a repeat, but I can try to reproduce and see what happens.
I do not believe there is anything in Guacamole specifically that deals with this, it should all be in libssh2, but we can take a look.
-Nick
Re: Connection failures
Posted by Nick Couchman <vn...@apache.org>.
On Wed, Jan 24, 2018 at 10:55 AM, <ha...@faa.gov> wrote:
> As a test, I made a new Guacamole connection to a server that we did NOT
> make FIPS 140-2 compliant yet, and was able to get right in. So the FIPS
> 140-2 is definitely the issue. So I need to know if there’s something in
> guacamole 0.9.13 that I need to tweak, or libssh2. I’m not sure if I can
> update libssh2 to a newer version, as 1.4.3 is the latest available in the
> RHEL 7.4 patch trail.
>
>
> Can you remind/post the changes made to make the SSH server FIPS 140-2
compliant? You may have already posted it, so apologies if that's a
repeat, but I can try to reproduce and see what happens.
I do not believe there is anything in Guacamole specifically that deals
with this, it should all be in libssh2, but we can take a look.
-Nick
RE: Connection failures
Posted by ha...@faa.gov.
As a test, I made a new Guacamole connection to a server that we did NOT make FIPS 140-2 compliant yet, and was able to get right in. So the FIPS 140-2 is definitely the issue. So I need to know if there’s something in guacamole 0.9.13 that I need to tweak, or libssh2. I’m not sure if I can update libssh2 to a newer version, as 1.4.3 is the latest available in the RHEL 7.4 patch trail.
Thanks,
Harry
From: Devine, Harry (FAA)
Sent: Wednesday, January 24, 2018 8:39 AM
To: user@guacamole.apache.org
Subject: RE: Connection failures
OK, I see that. Looks like it has support for it, however, I have libssh2 version 1.4.3 installed. I couldn’t find anything that says what 1.4.3 had support for. Assuming that it DOES support the FIPS algorithms, what settings for an SSH connection will I need to set to allow this? The only setting that looks close is the Encryption setting under “Guacamole Proxy Parameters (GUACD)”, but I’m not using it.
Thanks,
Harry
From: Nick Couchman [mailto:vnick@apache.org]
Sent: Wednesday, January 24, 2018 8:27 AM
To: user@guacamole.apache.org<ma...@guacamole.apache.org>
Subject: Re: Connection failures
On Mon, Jan 22, 2018 at 9:15 AM, <ha...@faa.gov>> wrote:
Guacd is running. I looked at /var/log/messages and encountered the following:
Jan 22 09:09:21 access guacd[1760]: Creating new client for protocol "ssh"
Jan 22 09:09:21 access guacd[1760]: Connection ID is "$e25765a1-e06d-4bd7-959c-2e7878839efe"
Jan 22 09:09:21 access guacd[30054]: User "@8e09fdad-3f86-4e2c-a85a-2c342e200921" joined connection "$e25765a1-e06d-4bd7-959c-2e7878839efe" (1 users now present)
Jan 22 09:09:21 access server: 09:09:21.596 [http-bio-8080-exec-8] INFO o.a.g.tunnel.TunnelRequestService - User "guacadmin" connected to connection "3".
Jan 22 09:09:30 access guacd[30054]: SSH handshake failed.
Jan 22 09:09:30 access guacd[30054]: User "@8e09fdad-3f86-4e2c-a85a-2c342e200921" disconnected (0 users remain)
Jan 22 09:09:30 access guacd[30054]: Last user of connection "$e25765a1-e06d-4bd7-959c-2e7878839efe" disconnected
Jan 22 09:09:30 access server: 09:09:30.808 [http-bio-8080-exec-8] INFO o.a.g.tunnel.TunnelRequestService - User "guacadmin" disconnected from connection "3". Duration: 9210 milliseconds
Jan 22 09:09:30 access server: Exception in thread "Thread-30" java.lang.IllegalStateException: Message will not be sent because the WebSocket session has been closed
Jan 22 09:09:30 access server: at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMessagePart(WsRemoteEndpointImplBase.java:387)
Jan 22 09:09:30 access server: at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessage(WsRemoteEndpointImplBase.java:344)
Jan 22 09:09:30 access server: at org.apache.tomcat.websocket.WsRemoteEndpointImplBase$TextMessageSendHandler.write(WsRemoteEndpointImplBase.java:788)
Jan 22 09:09:30 access server: at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendPartialString(WsRemoteEndpointImplBase.java:252)
Jan 22 09:09:30 access server: at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendString(WsRemoteEndpointImplBase.java:195)
Jan 22 09:09:30 access server: at org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(WsRemoteEndpointBasic.java:37)
Jan 22 09:09:30 access server: at org.apache.guacamole.websocket.GuacamoleWebSocketTunnelEndpoint$2.run(GuacamoleWebSocketTunnelEndpoint.java:167)
Jan 22 09:09:31 access guacd[1760]: Connection "$e25765a1-e06d-4bd7-959c-2e7878839efe" removed.
I will say this: late last week, we made all of our servers FIPS-2 compliant due to an IT requirement in our organization. I’m suspecting that, since the server I’m trying to connect to is now FIPS-2 compliant, that’s why the “SSH handshake failed” error is happening. But I don’t see anything in the connection setup to specify what encryption to use for SSH.
For SSH connections, the algorithms for Cipher and Key Exchange are determined by upstream support in the libssh2 library. You can see the current list of supported ciphers, hashes, key exchanges, etc., on the web site:
https://libssh2.org/
-Nick
RE: Connection failures
Posted by ha...@faa.gov.
OK, I see that. Looks like it has support for it, however, I have libssh2 version 1.4.3 installed. I couldn’t find anything that says what 1.4.3 had support for. Assuming that it DOES support the FIPS algorithms, what settings for an SSH connection will I need to set to allow this? The only setting that looks close is the Encryption setting under “Guacamole Proxy Parameters (GUACD)”, but I’m not using it.
Thanks,
Harry
From: Nick Couchman [mailto:vnick@apache.org]
Sent: Wednesday, January 24, 2018 8:27 AM
To: user@guacamole.apache.org
Subject: Re: Connection failures
On Mon, Jan 22, 2018 at 9:15 AM, <ha...@faa.gov>> wrote:
Guacd is running. I looked at /var/log/messages and encountered the following:
Jan 22 09:09:21 access guacd[1760]: Creating new client for protocol "ssh"
Jan 22 09:09:21 access guacd[1760]: Connection ID is "$e25765a1-e06d-4bd7-959c-2e7878839efe"
Jan 22 09:09:21 access guacd[30054]: User "@8e09fdad-3f86-4e2c-a85a-2c342e200921" joined connection "$e25765a1-e06d-4bd7-959c-2e7878839efe" (1 users now present)
Jan 22 09:09:21 access server: 09:09:21.596 [http-bio-8080-exec-8] INFO o.a.g.tunnel.TunnelRequestService - User "guacadmin" connected to connection "3".
Jan 22 09:09:30 access guacd[30054]: SSH handshake failed.
Jan 22 09:09:30 access guacd[30054]: User "@8e09fdad-3f86-4e2c-a85a-2c342e200921" disconnected (0 users remain)
Jan 22 09:09:30 access guacd[30054]: Last user of connection "$e25765a1-e06d-4bd7-959c-2e7878839efe" disconnected
Jan 22 09:09:30 access server: 09:09:30.808 [http-bio-8080-exec-8] INFO o.a.g.tunnel.TunnelRequestService - User "guacadmin" disconnected from connection "3". Duration: 9210 milliseconds
Jan 22 09:09:30 access server: Exception in thread "Thread-30" java.lang.IllegalStateException: Message will not be sent because the WebSocket session has been closed
Jan 22 09:09:30 access server: at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMessagePart(WsRemoteEndpointImplBase.java:387)
Jan 22 09:09:30 access server: at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessage(WsRemoteEndpointImplBase.java:344)
Jan 22 09:09:30 access server: at org.apache.tomcat.websocket.WsRemoteEndpointImplBase$TextMessageSendHandler.write(WsRemoteEndpointImplBase.java:788)
Jan 22 09:09:30 access server: at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendPartialString(WsRemoteEndpointImplBase.java:252)
Jan 22 09:09:30 access server: at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendString(WsRemoteEndpointImplBase.java:195)
Jan 22 09:09:30 access server: at org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(WsRemoteEndpointBasic.java:37)
Jan 22 09:09:30 access server: at org.apache.guacamole.websocket.GuacamoleWebSocketTunnelEndpoint$2.run(GuacamoleWebSocketTunnelEndpoint.java:167)
Jan 22 09:09:31 access guacd[1760]: Connection "$e25765a1-e06d-4bd7-959c-2e7878839efe" removed.
I will say this: late last week, we made all of our servers FIPS-2 compliant due to an IT requirement in our organization. I’m suspecting that, since the server I’m trying to connect to is now FIPS-2 compliant, that’s why the “SSH handshake failed” error is happening. But I don’t see anything in the connection setup to specify what encryption to use for SSH.
For SSH connections, the algorithms for Cipher and Key Exchange are determined by upstream support in the libssh2 library. You can see the current list of supported ciphers, hashes, key exchanges, etc., on the web site:
https://libssh2.org/
-Nick
Re: Connection failures
Posted by Nick Couchman <vn...@apache.org>.
On Mon, Jan 22, 2018 at 9:15 AM, <ha...@faa.gov> wrote:
> Guacd is running. I looked at /var/log/messages and encountered the
> following:
>
>
>
> Jan 22 09:09:21 access guacd[1760]: Creating new client for protocol "ssh"
>
> Jan 22 09:09:21 access guacd[1760]: Connection ID is
> "$e25765a1-e06d-4bd7-959c-2e7878839efe"
>
> Jan 22 09:09:21 access guacd[30054]: User "@8e09fdad-3f86-4e2c-a85a-2c342e200921"
> joined connection "$e25765a1-e06d-4bd7-959c-2e7878839efe" (1 users now
> present)
>
> Jan 22 09:09:21 access server: 09:09:21.596 [http-bio-8080-exec-8] INFO
> o.a.g.tunnel.TunnelRequestService - User "guacadmin" connected to
> connection "3".
>
> Jan 22 09:09:30 access guacd[30054]: SSH handshake failed.
>
> Jan 22 09:09:30 access guacd[30054]: User "@8e09fdad-3f86-4e2c-a85a-2c342e200921"
> disconnected (0 users remain)
>
> Jan 22 09:09:30 access guacd[30054]: Last user of connection
> "$e25765a1-e06d-4bd7-959c-2e7878839efe" disconnected
>
> Jan 22 09:09:30 access server: 09:09:30.808 [http-bio-8080-exec-8] INFO
> o.a.g.tunnel.TunnelRequestService - User "guacadmin" disconnected from
> connection "3". Duration: 9210 milliseconds
>
> Jan 22 09:09:30 access server: Exception in thread "Thread-30" java.lang.IllegalStateException:
> Message will not be sent because the WebSocket session has been closed
>
> Jan 22 09:09:30 access server: at org.apache.tomcat.websocket.
> WsRemoteEndpointImplBase.writeMessagePart(WsRemoteEndpointImplBase.java:
> 387)
>
> Jan 22 09:09:30 access server: at org.apache.tomcat.websocket.
> WsRemoteEndpointImplBase.startMessage(WsRemoteEndpointImplBase.java:344)
>
> Jan 22 09:09:30 access server: at org.apache.tomcat.websocket.
> WsRemoteEndpointImplBase$TextMessageSendHandler.write(
> WsRemoteEndpointImplBase.java:788)
>
> Jan 22 09:09:30 access server: at org.apache.tomcat.websocket.
> WsRemoteEndpointImplBase.sendPartialString(WsRemoteEndpointImplBase.java:
> 252)
>
> Jan 22 09:09:30 access server: at org.apache.tomcat.websocket.
> WsRemoteEndpointImplBase.sendString(WsRemoteEndpointImplBase.java:195)
>
> Jan 22 09:09:30 access server: at org.apache.tomcat.websocket.
> WsRemoteEndpointBasic.sendText(WsRemoteEndpointBasic.java:37)
>
> Jan 22 09:09:30 access server: at org.apache.guacamole.websocket.
> GuacamoleWebSocketTunnelEndpoint$2.run(GuacamoleWebSocketTunnelEndpoi
> nt.java:167)
>
> Jan 22 09:09:31 access guacd[1760]: Connection "$e25765a1-e06d-4bd7-959c-2e7878839efe"
> removed.
>
>
>
> I will say this: late last week, we made all of our servers FIPS-2
> compliant due to an IT requirement in our organization. I’m suspecting
> that, since the server I’m trying to connect to is now FIPS-2 compliant,
> that’s why the “SSH handshake failed” error is happening. But I don’t see
> anything in the connection setup to specify what encryption to use for SSH.
>
>
>
For SSH connections, the algorithms for Cipher and Key Exchange are
determined by upstream support in the libssh2 library. You can see the
current list of supported ciphers, hashes, key exchanges, etc., on the web
site:
https://libssh2.org/
-Nick
RE: Connection failures
Posted by ha...@faa.gov.
Guacd is running. I looked at /var/log/messages and encountered the following:
Jan 22 09:09:21 access guacd[1760]: Creating new client for protocol "ssh"
Jan 22 09:09:21 access guacd[1760]: Connection ID is "$e25765a1-e06d-4bd7-959c-2e7878839efe"
Jan 22 09:09:21 access guacd[30054]: User "@8e09fdad-3f86-4e2c-a85a-2c342e200921" joined connection "$e25765a1-e06d-4bd7-959c-2e7878839efe" (1 users now present)
Jan 22 09:09:21 access server: 09:09:21.596 [http-bio-8080-exec-8] INFO o.a.g.tunnel.TunnelRequestService - User "guacadmin" connected to connection "3".
Jan 22 09:09:30 access guacd[30054]: SSH handshake failed.
Jan 22 09:09:30 access guacd[30054]: User "@8e09fdad-3f86-4e2c-a85a-2c342e200921" disconnected (0 users remain)
Jan 22 09:09:30 access guacd[30054]: Last user of connection "$e25765a1-e06d-4bd7-959c-2e7878839efe" disconnected
Jan 22 09:09:30 access server: 09:09:30.808 [http-bio-8080-exec-8] INFO o.a.g.tunnel.TunnelRequestService - User "guacadmin" disconnected from connection "3". Duration: 9210 milliseconds
Jan 22 09:09:30 access server: Exception in thread "Thread-30" java.lang.IllegalStateException: Message will not be sent because the WebSocket session has been closed
Jan 22 09:09:30 access server: at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMessagePart(WsRemoteEndpointImplBase.java:387)
Jan 22 09:09:30 access server: at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessage(WsRemoteEndpointImplBase.java:344)
Jan 22 09:09:30 access server: at org.apache.tomcat.websocket.WsRemoteEndpointImplBase$TextMessageSendHandler.write(WsRemoteEndpointImplBase.java:788)
Jan 22 09:09:30 access server: at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendPartialString(WsRemoteEndpointImplBase.java:252)
Jan 22 09:09:30 access server: at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendString(WsRemoteEndpointImplBase.java:195)
Jan 22 09:09:30 access server: at org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(WsRemoteEndpointBasic.java:37)
Jan 22 09:09:30 access server: at org.apache.guacamole.websocket.GuacamoleWebSocketTunnelEndpoint$2.run(GuacamoleWebSocketTunnelEndpoint.java:167)
Jan 22 09:09:31 access guacd[1760]: Connection "$e25765a1-e06d-4bd7-959c-2e7878839efe" removed.
I will say this: late last week, we made all of our servers FIPS-2 compliant due to an IT requirement in our organization. I’m suspecting that, since the server I’m trying to connect to is now FIPS-2 compliant, that’s why the “SSH handshake failed” error is happening. But I don’t see anything in the connection setup to specify what encryption to use for SSH.
We also have an RDP connection that is failing too. That doesn’t fall under the FIPS-2 compliance as it’s a Windows box, and we didn’t make any changes to it. Here’s the log entries for that failed connection:
Jan 22 09:14:05 access guacd[1760]: Creating new client for protocol "rdp"
Jan 22 09:14:05 access guacd[1760]: Connection ID is "$13401d2e-99e0-4700-8194-89a802a5040c"
Jan 22 09:14:05 access guacd[30154]: No security mode specified. Defaulting to RDP.
Jan 22 09:14:05 access guacd[30154]: Resize method: none
Jan 22 09:14:05 access guacd[30154]: User "@4a854582-75d9-4b59-9343-fafc9d226b08" joined connection "$13401d2e-99e0-4700-8194-89a802a5040c" (1 users now present)
Jan 22 09:14:05 access server: 09:14:05.604 [http-bio-8080-exec-3] INFO o.a.g.tunnel.TunnelRequestService - User "guacadmin" connected to connection "5".
Jan 22 09:14:05 access guacd[30154]: Loading keymap "base"
Jan 22 09:14:05 access guacd[30154]: Loading keymap "en-us-qwerty"
Jan 22 09:14:05 access guacd[30154]: Failed to load cliprdr plugin. Clipboard will not work.
Jan 22 09:14:05 access guacd[30154]: Failed to load guacdr plugin. Drive redirection and printing will not work. Sound MAY not work.
Jan 22 09:14:05 access guacd[30154]: Failed to load guacsnd alongside guacdr plugin. Sound will not work. Drive redirection and printing MAY not work.
Jan 22 09:14:05 access abrt-hook-ccpp: Process 30154 (guacd) of user 0 killed by SIGABRT - ignoring (repeated crash)
Jan 22 09:14:05 access guacd[1760]: Connection "$13401d2e-99e0-4700-8194-89a802a5040c" removed.
Jan 22 09:14:10 access server: 09:14:10.539 [Thread-38] INFO o.a.g.tunnel.TunnelRequestService - User "guacadmin" disconnected from connection "5". Duration: 4935 milliseconds
Thanks,
Harry
From: Nick Couchman [mailto:vnick@apache.org]
Sent: Monday, January 22, 2018 9:05 AM
To: user@guacamole.apache.org
Subject: Re: Connection failures
On Mon, Jan 22, 2018 at 9:02 AM, <ha...@faa.gov>> wrote:
Today, when I try to connect to any connection we have in Guacamole (0.9.13), either an SSH or RDP connection, I get the following error:
[cid:image001.png@01D39361.5F5F0590]
I tried to look in the logs under /var/log/tomcat but didn’t see anything about any errors. What logs should I be looking at to find out what could be going on and fix this? We are hoping to roll our Guacamole implementation out to more users very soon, and we can’t have this type of erroring happening without knowing why and how to fix it.
The first thing I would check is to make sure that guacd is still running, and responsive - check /var/log/messages, or journalctl, and make sure there are messages from guacd, in addition to "ps -ef | grep guacd" to make sure it is actually running. If it isn't, restart it.
If it is running, take a look at the logs and figure out why it seems to be failing, and make sure you can connect to those systems from other SSH and/or Guacamole clients.
-Nick
Re: Connection failures
Posted by Nick Couchman <vn...@apache.org>.
On Mon, Jan 22, 2018 at 9:02 AM, <ha...@faa.gov> wrote:
> Today, when I try to connect to any connection we have in Guacamole
> (0.9.13), either an SSH or RDP connection, I get the following error:
>
>
>
>
>
> I tried to look in the logs under /var/log/tomcat but didn’t see anything
> about any errors. What logs should I be looking at to find out what could
> be going on and fix this? We are hoping to roll our Guacamole
> implementation out to more users very soon, and we can’t have this type of
> erroring happening without knowing why and how to fix it.
>
>
>
The first thing I would check is to make sure that guacd is still running,
and responsive - check /var/log/messages, or journalctl, and make sure
there are messages from guacd, in addition to "ps -ef | grep guacd" to make
sure it is actually running. If it isn't, restart it.
If it is running, take a look at the logs and figure out why it seems to be
failing, and make sure you can connect to those systems from other SSH
and/or Guacamole clients.
-Nick