You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@guacamole.apache.org by "Patrick Sullivan (JIRA)" <ji...@apache.org> on 2019/01/16 00:03:00 UTC

[jira] [Created] (GUACAMOLE-703) SSH Handshake Failed to Non-linux Shell SSH Server(?)

Patrick Sullivan created GUACAMOLE-703:
------------------------------------------

             Summary: SSH Handshake Failed to Non-linux Shell SSH Server(?)
                 Key: GUACAMOLE-703
                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-703
             Project: Guacamole
          Issue Type: Bug
          Components: SSH
    Affects Versions: 0.9.14
            Reporter: Patrick Sullivan


When attempting to use Guacamole 0.9.14 to connect via SSH to an Appliance that has a proprietary shell (non-bash), SSH connects to the server via Guac, however disconnects after password is submitted.

Event logs on Guac server show 'SSH Handshake Failed', but no other info. Able to connect to the appliance using Putty, Terraterm SSH clients, and able to SSH from Guac server CLI also without issue. 

Only occurs on SSH servers where the vendor has implemented their own restricted shell, e.g. as many pre-packaged virtual appliances have. 

Log excerpts below. 

 
GUAC Log
===============================
Jan 15 18:53:33 <hostname> guacd[7046]: User "@abf93eb1-fef9-4bb6-908d-bd5316093b0d" joined connection "$92e78549-bd3e-4743-97e6-54925ada845a" (1 users now present)
Jan 15 18:53:33 <hostname> server: 18:53:33.404 [http-bio-8443-exec-4] INFO  o.a.g.tunnel.TunnelRequestService - User "guacadmin" connected to connection "15".
Jan 15 18:53:38 <hostname> guacd[7046]: SSH handshake failed.
Jan 15 18:53:38 <hostname> guacd[7046]: User "@abf93eb1-fef9-4bb6-908d-bd5316093b0d" disconnected (0 users remain)
Jan 15 18:53:38 <hostname> guacd[7046]: Last user of connection "$92e78549-bd3e-4743-97e6-54925ada845a" disconnected
 
In the below log except, taken from a working client (PUtty), the Guac server usually disconnects between the '<—XXXXXXXXX—>' parts of the sequence straight after the user provides the password, appears to be when the server switches to it's proprietary shell. 

From a (Working) SSH Client Log to the affected SSH Server/Appliance
===============================
Event Log: Server version: SSH-2.0-OpenSSH_5.3
Event Log: We believe remote version has SSH-2 channel request bug
Event Log: Using SSH protocol version 2
Event Log: Doing Diffie-Hellman group exchange
Event Log: Doing Diffie-Hellman key exchange with hash SHA-256
Event Log: Host key fingerprint is:
Event Log: Initialised AES-256 SDCTR client->server encryption
Event Log: Initialised HMAC-SHA-256 client->server MAC algorithm
Event Log: Initialised AES-256 SDCTR server->client encryption
Event Log: Initialised HMAC-SHA-256 server->client MAC algorithm
Event Log: Sent password
<---XXXXXXXX--->
Event Log: Access granted
Event Log: Opening session as main channel
Event Log: Opened main channel                                 
Event Log: Allocated pty (ospeed 38400bps, ispeed 38400bps)                                
Event Log: Started a shell/command
Incoming packet #0x9, type 93 / 0x5d (SSH2_MSG_CHANNEL_WINDOW_ADJUST) 
<---XXXXXXXX--->



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)