Re: SSH handshake failed: only RSA keys possible?

2017-12-24 Thread Nick Couchman
On Sat, Dec 23, 2017 at 10:41 PM, NTMMFTS  wrote:

> It appears that libssh2 includes the aes256-cbc key exchange method
> supported
> by pfSense, so I modded the ssh.c code and let it compile during
> installation using hanaciamiento's guacamole install script
> (https://sourceforge.net/projects/guacamoleinstallscript/), but guacamole
> won't load at all afterwards.
>
> Here's the code and where I inserted it in ssh.c in the
> guac_common_ssh_create_session function:
>
> /* Open SSH session */
> // existing code
>
> /* added preferred method for key exchange method supported by
> pfSense */
> int returnval = libssh2_session_method_pref(session,
> LIBSSH2_METHOD_CRYPT_CS, "aes256-cbc");
> if (returnval != 0) {
> guac_client_abort(client, GUAC_PROTOCOL_STATUS_SERVER_ERROR,
> "Setting session preferred key exchange method to
> AES256-CBC
> failed.");
> free(common_session);
> close(fd);
> return NULL;
> }
>
> /* Perform handshake */
> // existing code
>

First, I don't think this should be necessary to get it working if libssh2
supports that crypt method.  I believe it will use any supported method
without having to set it as a preferred method, no?  That said, setting it
as preferred should not impede the connection, either, so this should be
fine.


>
> Anyone want to comment on this approach or try to get it working?
>

With guacd in debug mode (guacd -L debug), what messages do you see during
the SSH connection?  Also, when you say it "won't load at all with it
afterwards," what does this mean?  It segfaults?  Or guacd runs but the
connection doesn't start?  Or sometihng else?

-Nick


Re: Printing using docker image?

2017-12-24 Thread Jonathan Hunter
Hi All,

Just to follow up on this and for the benefit of others having the same
issue, I have now successfully worked around the problem.

Printing does not work (for me, at least) when using guacamole via an
Apache reverse proxy *in HTTP mode*. I am not sure if this counts as a bug
- since everything else i.e. normal interactive use of guacamole
RDP/VNC/SSH/etc. sessions work fine in this configuration - but here are
the two steps I took to resolve:

- Install Apache's mod_proxy_wstunnel (on Debian this is 'sudo a2enmod
proxy_wstunnel')
- Add a line in Apache's config to websocket-proxy the relevant URL. Note
that this line must come *before* the config entry that proxies the rest of
guacamole, since Apache's ProxyPass command operates on a first match wins
basis.

(I did look at Chapter 4 of the documentation, and in particular the
'Proxying with websocket' section, but I found I did not need the
ProxyPassReverse statement shown there; nor did I need to place it within a
 section, in my config at least.)

My Apache config now looks like this:

ProxyPass /remoteaccess/websocket-tunnel
ws://docker.host:5678/guacamole/websocket-tunnel

ProxyPass /remoteaccess/
http://docker.host:5678/guacamole/

and printing now works perfectly.

Mike/team - is this a bug? (Printing works via websocket but not via http)
and if so, is there a bug tracker I should report this to? Happy to do some
more digging/testing, if this isn't reproducible elsewhere.

Thanks - and season's greetings to all!

Cheers,

Jonathan

On 22 December 2017 at 08:05, Jonathan Hunter  wrote:

> Thanks Mike, that helps!
>
> I do indeed have ghostscript installed, and the /usr/bin/gs binary does
> exist, in the guacd image, which is great.
>
> I've just tried it again (printed a simple Notepad document saying
> 'hello'). It seems to take a long time to think about whatever it is doing,
> since the web browser window does indicate at the bottom that something is
> happening, but then gives up / times out.
>
> What actually happens after I press 'Print' on the Windows machine (I am
> connecting to it via RDP) is that guacd says:
>
> guacd[949]: INFO:   Print job created
>
> guacd[949]: INFO:   Created PDF filter process PID=958
>
> guacd[958]: INFO:   Running gs
> and the web browser I am using (Chrome on Mac) flashes up "Waiting for
> www.myurl.com" at the bottom of the browser window a few times - but then
> nothing else happens. No further log items come up. (I am using 'docker
> logs -f guacd' to view these)
>
> Are there any built-in hooks to turn up debugging levels etc. in guacd
> when using it via docker, or should I do my normal mechanism of running
> /bin/sh in the docker container and running strace -f ?
>
> I wonder if it might be related to my use of Apache as a reverse proxy in
> front of the docker container; but that works fine for normal interactive
> use of guacamole, I've not had a problem yet. The Apache config is pretty
> much just:
>
> ProxyPass /remoteaccess/http://docker.host:5678/guacamole/
> but perhaps this interfers with printing somehow.
>
> Update - I have tried connecting direct to the docker image (I needed to
> find a plugin for Chrome to set the REMOTE_USER header as I am using HTTP
> authentication on my reverse proxy) and printing *does* work perfectly this
> way. So, it is not guacd, but rather something to do with my use of Apache
> as a reverse proxy.
>
> Going direct instead of via Apache, I get the following in guacd logs:
>
> guacd[993]: INFO:   Print job created
>
> guacd[993]: INFO:   Created PDF filter process PID=1002
>
> guacd[1002]: INFO:  Running gs
>
> guacd[993]: INFO:   Print job closed
>
> guacd[993]: INFO:   Ignoring printer cached configuration data
>
> Any pointers appreciated..
>
> Many thanks :)
>
> Jonathan
>
> On 21 December 2017 at 01:31, Mike Jumper 
> wrote:
>
>> On Dec 20, 2017 17:26, "Jonathan Hunter"  wrote:
>>
>> ...
>>
>> The following command returns nothing for me:
>>
>> # docker exec -it guacamole find / -type f -name gs
>>
>> Am I barking up the wrong tree here?
>>
>>
>> Yep. You need to bark up the guacd tree instead. ;)
>>
>> It's not the guacamole image which needs GhostScript, but the guacd
>> image. It should be there, though. It's installed as part of the image
>> build:
>>
>> https://github.com/apache/guacamole-server/blob/f72de10328ae
>> 39fcbf067333b0c2a2c9aecc441b/Dockerfile#L36
>>
>> - Mike
>>
>>
>
>
> --
> "If we knew what it was we were doing, it would not be called research,
> would it?"
>   - Albert Einstein
>



-- 
"If we knew what it was we were doing, it would not be called research,
would it?"
  - Albert Einstein