[
https://issues.apache.org/jira/browse/GUACAMOLE-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225072#comment-17225072
]
Mike Jumper edited comment on GUACAMOLE-1206 at 11/3/20, 2:02 AM:
------------------------------------------------------------------
{quote}
If I read correctly changes were made in 1.1.0 to interrogate the remote SSH
server for stuff like the shell used, setting the TZ and locale.
{quote}
Not to interrogate the remote server, but to offer up additional information
for consumption by the SSH server. If the SSH server doesn't support that, then
warnings are logged and things proceed as normal. This shouldn't be causing any
failures.
The line regarding zero keyboard-interactive prompts is suspicious.
{quote}
All our old connections have been redone in the configuration and work
seamlessly except this one. SSH connections with 'normal' OpenSSH servers are
working perfectly.
{quote}
When you say "all our old connections" here, are you referring to all
connections except a connection to the Spectra Logic storage box you mentioned?
All other connections are working and all other connections are to standard
OpenSSH servers?
{quote}
Pretty sure that this new handshake is not working in this context. How should
I investigate this and is there a way to revert to the old behavior ?
{quote}
I think it is early to assume that this is due to these changes. The changes
you're referring to _should_ be benign. If an older release worked (and you
have verified that said old release still works), then presumably something has
changed, however there is a huge sea of changes to cover between something as
old as 0.9.8 and the present day:
{code:none}
[mjumper@dev-mjumper guacamole-server]$ git diff --stat 0.9.8..1.2.0
src/protocols/ssh/ src/common-ssh/
...
49 files changed, 5269 insertions(+), 2478 deletions(-)
[mjumper@dev-mjumper guacamole-server]$
{code}
Are you familiar with {{git bisect}}? To investigate, I would recommend:
# *Confirm that 0.9.8 does indeed still work.* It's important to eliminate
broken configuration or external changes as factors.
# If 0.9.8 does still work, walk, *try a few other releases* between then and
now. I would bounce back and forth a bit, in a sort of binary search, to try to
narrow the window between the last release that worked and the first that
broke. There _should_ be exactly one release where things cease working, not a
wide swath of releases like 0.9.8 and 1.2.0.
# Once you have the first known release to fail, do a {{git bisect}} between
the previous release (which would be known good) and the failing release (which
would be known bad). The bisect process will walk through individual commits,
asking you to tell git whether the current commit is "good" or "bad". You would
do the usual build steps ({{make}}, {{make install}}, and {{ldconfig}}), start
guacd, test whether things are working, and let git know.
After a few builds like that, git should give you exactly one commit that broke
things.
was (Author: mike.jumper):
{quote}
If I read correctly changes were made in 1.1.0 to interrogate the remote SSH
server for stuff like the shell used, setting the TZ and locale.
{quote}
Not to interrogate the remote server, but to offer up additional information
for consumption by the SSH server. If the SSH server doesn't support that, then
warnings are logged and things proceed as normal. This shouldn't be causing any
failures.
The line regarding zero keyboard-interactive prompts is suspicious.
{quote}
All our old connections have been redone in the configuration and work
seamlessly except this one.
{quote}
When you say "all our old connections" here, are you referring to all
connections except a connection to the Spectra Logic storage box you mentioned?
SSH connections with 'normal' OpenSSH servers are working perfectly. All other
connections are working and all other connections are to standard OpenSSH
servers?
{quote}
Pretty sure that this new handshake is not working in this context. How should
I investigate this and is there a way to revert to the old behavior ?
{quote}
I think it is early to assume that this is due to these changes. The changes
you're referring to _should_ be benign. If an older release worked (and you
have verified that said old release still works), then presumably something has
changed, however there is a huge sea of changes to cover between something as
old as 0.9.8 and the present day:
{code:none}
[mjumper@dev-mjumper guacamole-server]$ git diff --stat 0.9.8..1.2.0
src/protocols/ssh/ src/common-ssh/
...
49 files changed, 5269 insertions(+), 2478 deletions(-)
[mjumper@dev-mjumper guacamole-server]$
{code}
Are you familiar with {{git bisect}}? To investigate, I would recommend:
# *Confirm that 0.9.8 does indeed still work.* It's important to eliminate
broken configuration or external changes as factors.
# If 0.9.8 does still work, walk, *try a few other releases* between then and
now. I would bounce back and forth a bit, in a sort of binary search, to try to
narrow the window between the last release that worked and the first that
broke. There _should_ be exactly one release where things cease working, not a
wide swath of releases like 0.9.8 and 1.2.0.
# Once you have the first known release to fail, do a {{git bisect}} between
the previous release (which would be known good) and the failing release (which
would be known bad). The bisect process will walk through individual commits,
asking you to tell git whether the current commit is "good" or "bad". You would
do the usual build steps ({{make}}, {{make install}}, and {{ldconfig}}), start
guacd, test whether things are working, and let git know.
After a few builds like that, git should give you exactly one commit that broke
things.
> SSH connection - restricted shell
> ---------------------------------
>
> Key: GUACAMOLE-1206
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1206
> Project: Guacamole
> Issue Type: Bug
> Components: guacd, SSH
> Affects Versions: 1.2.0
> Environment: Ubuntu 20.04, docker 19.03.13, Guacamole 1.2.0
> Reporter: Luc Prefontaine
> Priority: Major
>
> We have a Spectra Logic storage box here and the remote console uses SSH but
> with a restricted shell, not a standard shell (sh/bash/whatever). When
> attempting to connect, guacd stalls and never returns (or I wasn't patient
> enough to wait several minutes). This was working in 0.9.8. If I read
> correctly changes were made in 1.1.0 to interrogate the remote SSH server for
> stuff like the shell used, setting the TZ and locale.
> All our old connections have been redone in the configuration and work
> seamlessly except this one. SSH connections with 'normal' OpenSSH servers
> are working perfectly. Pretty sure that this new handshake is not working in
> this context. How should I investigate this and is there a way to revert to
> the old behavior ?
> Messages outputted by guacd:
> {code:none}
> guacd[6]: INFO: Creating new client for protocol "ssh"
> guacd[6]: INFO: Connection ID is "$af567702-1461-451c-8238-c2f50fa16a01"
> guacd[1876]: INFO: User "@91f7ab2c-6970-4f40-a3bc-0640160da256" joined
> connection "$af567702-1461-451c-8238-c2f50fa16a01" (1 users now present)
> guacd[1876]: WARNING: No known host keys provided, host identity will not
> be verified.
> guacd[1876]: WARNING: Unsupported number of keyboard-interactive prompts: 0
> guacd[1876]: WARNING: Unable to set the timezone: SSH server refused to set
> "TZ" variable.
> guacd[1876]: WARNING: No known host keys provided, host identity will not
> be verified.
> guacd[1876]: WARNING: Unsupported number of keyboard-interactive prompts: 0
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
