[jira] [Updated] (GUACAMOLE-1128) Add account auto-create options to Docker
[ https://issues.apache.org/jira/browse/GUACAMOLE-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-1128: - Component/s: (was: guacamole-auth-jdbc-sqlserver) Documentation > Add account auto-create options to Docker > - > > Key: GUACAMOLE-1128 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1128 > Project: Guacamole > Issue Type: Improvement > Components: Documentation, guacamole-auth-jdbc-mysql, > guacamole-auth-jdbc-postgresql >Reporter: Nick Couchman >Assignee: Nick Couchman >Priority: Minor > > GUACAMOLE-708 was successfully implemented as part of the 1.2.0 release, but > the variables for the docker script to allow auto-create to be enabled where > not added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-1133) VNC fails to connect to macOS
[
https://issues.apache.org/jira/browse/GUACAMOLE-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256171#comment-17256171
]
Ryan Sleeth commented on GUACAMOLE-1133:
Just to confirm, version 1.2.0 and VNC username password authentication works
with all versions of Mac I've tested with. Users login with Active Directory
credentials which are then passed to the VNC connects using ${GUAC_USERNAME}
and ${GUAC_PASSWORD}.
> VNC fails to connect to macOS
> -
>
> Key: GUACAMOLE-1133
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1133
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole
>Affects Versions: 1.2.0
> Environment: Remote host macOS 10.15.5
> Guacamole server Raspbian GNU/Linux 10
>Reporter: Matt Fusfield
>Assignee: Nick Couchman
>Priority: Minor
>
> Since upgrading to version 1.2.0, I am unable to connect via VNC to a Mac
> host. The same exact configuration works with 1.1.0.
>
> In syslog, there are entries regarding "Selecting security type 30" and then
> it receives back types 33, 36,2,35. Then "VNC connection failed:
> authentication or authorization failure"
>
> I attempted to change config to use mac username and password, and that did
> not work either (on 1.1.0 the password is set to the Mac VNC password)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GUACAMOLE-1133) VNC fails to connect to macOS
[
https://issues.apache.org/jira/browse/GUACAMOLE-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256171#comment-17256171
]
Ryan Sleeth edited comment on GUACAMOLE-1133 at 12/29/20, 9:23 PM:
---
Just to confirm, version 1.2.0 and VNC username password authentication works
with all versions of Mac I've tested with. Users login with Active Directory
credentials which are then passed to the VNC connections using ${GUAC_USERNAME}
and ${GUAC_PASSWORD}.
was (Author: crsleeth):
Just to confirm, version 1.2.0 and VNC username password authentication works
with all versions of Mac I've tested with. Users login with Active Directory
credentials which are then passed to the VNC connects using ${GUAC_USERNAME}
and ${GUAC_PASSWORD}.
> VNC fails to connect to macOS
> -
>
> Key: GUACAMOLE-1133
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1133
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole
>Affects Versions: 1.2.0
> Environment: Remote host macOS 10.15.5
> Guacamole server Raspbian GNU/Linux 10
>Reporter: Matt Fusfield
>Assignee: Nick Couchman
>Priority: Minor
>
> Since upgrading to version 1.2.0, I am unable to connect via VNC to a Mac
> host. The same exact configuration works with 1.1.0.
>
> In syslog, there are entries regarding "Selecting security type 30" and then
> it receives back types 33, 36,2,35. Then "VNC connection failed:
> authentication or authorization failure"
>
> I attempted to change config to use mac username and password, and that did
> not work either (on 1.1.0 the password is set to the Mac VNC password)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GUACAMOLE-745) Add support for OpenSSH private key format
[
https://issues.apache.org/jira/browse/GUACAMOLE-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256169#comment-17256169
]
Nick Couchman edited comment on GUACAMOLE-745 at 12/29/20, 9:17 PM:
{quote}Perhaps this format is documented and our code just needs to do a bit
more for OpenSSH keys?
{quote}
Yeah, i was also looking at some of the OpenSSL functions for this, and there
seems to be a more generic `PEM_read_bio_PrivateKey()` function that reads more
generically and perhaps can be combined with other functions to determine the
type of the key on-the-fly?
{quote}I wonder if perhaps libssh would magically support this without us
having to manually parse provided keys.
{quote}
That would be lovely - it does seem like something that would be implemented in
a client library, though apparently libssh2 doesn't do it. Or maybe it does,
but the documentation on public key authentication for libssh2 is missing :(.
I was also looking at possible ways to use the Passphrase Callback prompt the
user for a private key passphrase rather than requiring it be specified in the
configuration, particularly now that we have parameter prompting included. This
would pave the way for user-specific private keys as mentioned in a different
JIRA issue.
was (Author: nick.couch...@yahoo.com):
{{quote}}
Perhaps this format is documented and our code just needs to do a bit more for
OpenSSH keys?
{{quote}}
Yeah, i was also looking at some of the OpenSSL functions for this, and there
seems to be a more generic `PEM_read_bio_PrivateKey()` function that reads more
generically and perhaps can be combined with other functions to determine the
type of the key on-the-fly?
{{quote}}
I wonder if perhaps libssh would magically support this without us having to
manually parse provided keys.
{{quote}}
That would be lovely - it does seem like something that would be implemented in
a client library, though apparently libssh2 doesn't do it. Or maybe it does,
but the documentation on public key authentication for libssh2 is missing :-(.
I was also looking at possible ways to use the Passphrase Callback prompt the
user for a private key passphrase rather than requiring it be specified in the
configuration, particularly now that we have parameter prompting included. This
would pave the way for user-specific private keys as mentioned in a different
JIRA issue.
> Add support for OpenSSH private key format
> --
>
> Key: GUACAMOLE-745
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-745
> Project: Guacamole
> Issue Type: Improvement
> Components: guacd, SSH
> Environment: Docker official images 1.0.0
>Reporter: Julien Nicoulaud
>Priority: Minor
>
> Since OpenSSH 7.8, {{ssh-keygen}} does not generate keys in PEM format by
> default anymore: [https://www.openssh.com/txt/release-7.8]
> Attempting to use keys in the new format in Guacamole does not work, and does
> not print any helpful error message even in debug mode:
> {code:java}
> guacd_1 | guacd[296]: DEBUG: Attempting private key import
> (WITHOUT passphrase)
> guacd_1 | guacd[296]: DEBUG: Initial import failed: (null)
> guacd_1 | guacd[296]: DEBUG: Re-attempting private key import
> (WITH passphrase)
> guacd_1 | guacd[296]: ERROR: Auth key import failed: (null){code}
> It would be nice if keys in OpenSSH new format were supported. At least a
> more helpful error message should be printed (like "unrecognized key format").
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-745) Add support for OpenSSH private key format
[
https://issues.apache.org/jira/browse/GUACAMOLE-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256169#comment-17256169
]
Nick Couchman commented on GUACAMOLE-745:
-
{{quote}}
Perhaps this format is documented and our code just needs to do a bit more for
OpenSSH keys?
{{quote}}
Yeah, i was also looking at some of the OpenSSL functions for this, and there
seems to be a more generic `PEM_read_bio_PrivateKey()` function that reads more
generically and perhaps can be combined with other functions to determine the
type of the key on-the-fly?
{{quote}}
I wonder if perhaps libssh would magically support this without us having to
manually parse provided keys.
{{quote}}
That would be lovely - it does seem like something that would be implemented in
a client library, though apparently libssh2 doesn't do it. Or maybe it does,
but the documentation on public key authentication for libssh2 is missing :-(.
I was also looking at possible ways to use the Passphrase Callback prompt the
user for a private key passphrase rather than requiring it be specified in the
configuration, particularly now that we have parameter prompting included. This
would pave the way for user-specific private keys as mentioned in a different
JIRA issue.
> Add support for OpenSSH private key format
> --
>
> Key: GUACAMOLE-745
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-745
> Project: Guacamole
> Issue Type: Improvement
> Components: guacd, SSH
> Environment: Docker official images 1.0.0
>Reporter: Julien Nicoulaud
>Priority: Minor
>
> Since OpenSSH 7.8, {{ssh-keygen}} does not generate keys in PEM format by
> default anymore: [https://www.openssh.com/txt/release-7.8]
> Attempting to use keys in the new format in Guacamole does not work, and does
> not print any helpful error message even in debug mode:
> {code:java}
> guacd_1 | guacd[296]: DEBUG: Attempting private key import
> (WITHOUT passphrase)
> guacd_1 | guacd[296]: DEBUG: Initial import failed: (null)
> guacd_1 | guacd[296]: DEBUG: Re-attempting private key import
> (WITH passphrase)
> guacd_1 | guacd[296]: ERROR: Auth key import failed: (null){code}
> It would be nice if keys in OpenSSH new format were supported. At least a
> more helpful error message should be printed (like "unrecognized key format").
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-745) Add support for OpenSSH private key format
[
https://issues.apache.org/jira/browse/GUACAMOLE-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256146#comment-17256146
]
Mike Jumper commented on GUACAMOLE-745:
---
I wonder if perhaps libssh would magically support this without us having to
manually parse provided keys.
> Add support for OpenSSH private key format
> --
>
> Key: GUACAMOLE-745
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-745
> Project: Guacamole
> Issue Type: Improvement
> Components: guacd, SSH
> Environment: Docker official images 1.0.0
>Reporter: Julien Nicoulaud
>Priority: Minor
>
> Since OpenSSH 7.8, {{ssh-keygen}} does not generate keys in PEM format by
> default anymore: [https://www.openssh.com/txt/release-7.8]
> Attempting to use keys in the new format in Guacamole does not work, and does
> not print any helpful error message even in debug mode:
> {code:java}
> guacd_1 | guacd[296]: DEBUG: Attempting private key import
> (WITHOUT passphrase)
> guacd_1 | guacd[296]: DEBUG: Initial import failed: (null)
> guacd_1 | guacd[296]: DEBUG: Re-attempting private key import
> (WITH passphrase)
> guacd_1 | guacd[296]: ERROR: Auth key import failed: (null){code}
> It would be nice if keys in OpenSSH new format were supported. At least a
> more helpful error message should be printed (like "unrecognized key format").
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-745) Add support for OpenSSH private key format
[
https://issues.apache.org/jira/browse/GUACAMOLE-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256144#comment-17256144
]
Mike Jumper commented on GUACAMOLE-745:
---
For OpenSSH itself to be able to read these keys, there's likely some way that
it identifies the type beyond simply brute forcing through all supported types.
Decoding generated keys with base64, I see "ssh-ed25519" in the content of the
key for the {{-t ed25519}} one and "ssh-rsa" for the {{-t rsa}} one. Perhaps
this format is documented and our code just needs to do a bit more for OpenSSH
keys?
> Add support for OpenSSH private key format
> --
>
> Key: GUACAMOLE-745
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-745
> Project: Guacamole
> Issue Type: Improvement
> Components: guacd, SSH
> Environment: Docker official images 1.0.0
>Reporter: Julien Nicoulaud
>Priority: Minor
>
> Since OpenSSH 7.8, {{ssh-keygen}} does not generate keys in PEM format by
> default anymore: [https://www.openssh.com/txt/release-7.8]
> Attempting to use keys in the new format in Guacamole does not work, and does
> not print any helpful error message even in debug mode:
> {code:java}
> guacd_1 | guacd[296]: DEBUG: Attempting private key import
> (WITHOUT passphrase)
> guacd_1 | guacd[296]: DEBUG: Initial import failed: (null)
> guacd_1 | guacd[296]: DEBUG: Re-attempting private key import
> (WITH passphrase)
> guacd_1 | guacd[296]: ERROR: Auth key import failed: (null){code}
> It would be nice if keys in OpenSSH new format were supported. At least a
> more helpful error message should be printed (like "unrecognized key format").
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GUACAMOLE-745) Add support for OpenSSH private key format
[
https://issues.apache.org/jira/browse/GUACAMOLE-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256089#comment-17256089
]
Nick Couchman edited comment on GUACAMOLE-745 at 12/29/20, 5:55 PM:
Digging into this issue and GUACAMOLE-746 a little more, it looks like the
changes are going to be a bit more involved than just allowing another header
format - currently the code uses the header to detect the type of key (RSA,
DSA, etc.); however, it appears that generating an OpenSSH key in either RSA
format or ED25519 format both result in the new header "BEGIN OPENSSH PRIVATE
KEY" - the header is no longer a valid indication of the key format. This means
our code is likely going to have to loop through supported formats and attempt
to load the key, or we're going to have to have an option for the user to
specify the key format.
{code:java}
[nick_couchman@localhost ~]$ ssh-keygen -t rsa -b 4096 -f ./openssh-rsa
Generating public/private rsa key pair.
...
[nick_couchman@localhost ~]$ head -n 1 ./openssh-rsa
-BEGIN OPENSSH PRIVATE KEY-
[nick_couchman@localhost ~]$ ssh-keygen -t ed25519 -b 4096 -f ./openssh-ed25519
Generating public/private ed25519 key pair.
...
[nick_couchman@localhost ~]$ head -n 1 ./openssh-ed25519
-BEGIN OPENSSH PRIVATE KEY-
{code}
was (Author: nick.couch...@yahoo.com):
Digging into this issue and GUACAMOLE-746 a little more, it looks like the
changes are going to be a bit more involved than just allowing another header
format - currently the code uses the header to detect the type of key (RSA,
DSA, etc.); however, it appears that generating an OpenSSH key in either RSA
format or ED25519 format both result in the new header "BEGIN OPENSSH PRIVATE
KEY" - the header is no longer a valid indication of the key format. This means
our code is likely going to have to loop through supported formats and attempt
to load the key, or we're going to have to have an option for the user to
specify the key format.
> Add support for OpenSSH private key format
> --
>
> Key: GUACAMOLE-745
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-745
> Project: Guacamole
> Issue Type: Improvement
> Components: guacd, SSH
> Environment: Docker official images 1.0.0
>Reporter: Julien Nicoulaud
>Priority: Minor
>
> Since OpenSSH 7.8, {{ssh-keygen}} does not generate keys in PEM format by
> default anymore: [https://www.openssh.com/txt/release-7.8]
> Attempting to use keys in the new format in Guacamole does not work, and does
> not print any helpful error message even in debug mode:
> {code:java}
> guacd_1 | guacd[296]: DEBUG: Attempting private key import
> (WITHOUT passphrase)
> guacd_1 | guacd[296]: DEBUG: Initial import failed: (null)
> guacd_1 | guacd[296]: DEBUG: Re-attempting private key import
> (WITH passphrase)
> guacd_1 | guacd[296]: ERROR: Auth key import failed: (null){code}
> It would be nice if keys in OpenSSH new format were supported. At least a
> more helpful error message should be printed (like "unrecognized key format").
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-745) Add support for OpenSSH private key format
[
https://issues.apache.org/jira/browse/GUACAMOLE-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256089#comment-17256089
]
Nick Couchman commented on GUACAMOLE-745:
-
Digging into this issue and GUACAMOLE-746 a little more, it looks like the
changes are going to be a bit more involved than just allowing another header
format - currently the code uses the header to detect the type of key (RSA,
DSA, etc.); however, it appears that generating an OpenSSH key in either RSA
format or ED25519 format both result in the new header "BEGIN OPENSSH PRIVATE
KEY" - the header is no longer a valid indication of the key format. This means
our code is likely going to have to loop through supported formats and attempt
to load the key, or we're going to have to have an option for the user to
specify the key format.
> Add support for OpenSSH private key format
> --
>
> Key: GUACAMOLE-745
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-745
> Project: Guacamole
> Issue Type: Improvement
> Components: guacd, SSH
> Environment: Docker official images 1.0.0
>Reporter: Julien Nicoulaud
>Priority: Minor
>
> Since OpenSSH 7.8, {{ssh-keygen}} does not generate keys in PEM format by
> default anymore: [https://www.openssh.com/txt/release-7.8]
> Attempting to use keys in the new format in Guacamole does not work, and does
> not print any helpful error message even in debug mode:
> {code:java}
> guacd_1 | guacd[296]: DEBUG: Attempting private key import
> (WITHOUT passphrase)
> guacd_1 | guacd[296]: DEBUG: Initial import failed: (null)
> guacd_1 | guacd[296]: DEBUG: Re-attempting private key import
> (WITH passphrase)
> guacd_1 | guacd[296]: ERROR: Auth key import failed: (null){code}
> It would be nice if keys in OpenSSH new format were supported. At least a
> more helpful error message should be printed (like "unrecognized key format").
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-925) Add Russian keyboard support for RDP
[ https://issues.apache.org/jira/browse/GUACAMOLE-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256088#comment-17256088 ] NFisher commented on GUACAMOLE-925: --- I've also edited Makefiles in protocols/rdp and rebuilt and reinstalled "guacd". During the "make" process i saw that ru_ru_qwerty.keymap was catched up to the build. But there's no option in "Keyboard layout" anyway. > Add Russian keyboard support for RDP > > > Key: GUACAMOLE-925 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-925 > Project: Guacamole > Issue Type: Improvement > Components: RDP >Affects Versions: 1.0.0 >Reporter: Roman Adyev >Priority: Minor > Attachments: SCREEN.jpg, apache_guacamole_Russian_layouts.txt, > ru_ru_qwerty.keymap > > > Hello, dear support team! > I'm using Unicode layout because Russian layout isn't presented there, but > with Unicode layout I can't send keyboard shortcuts to remote RDP machine > (CTRL + C for example). > If I switch Unicode to English layout in connection settings, I can do > keyboard shortcuts but unfortunately some signs doesn't match when I use RU > layout, for example instead of period sign I got Russian letter "ю". > The keyboard layouts on remote and local machine are identical, that's 100%, > tested many times on different clean windows 10 installs, on work, on VMs, on > friend's PCs, etc. The issue always the same. > As I can see Russian layout isn't presented in Guacamole connection settings > by itself so it would be highly appreciated if you can suggest any workaround > for Russian users. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-1133) VNC fails to connect to macOS
[ https://issues.apache.org/jira/browse/GUACAMOLE-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256034#comment-17256034 ] Matt Fusfield commented on GUACAMOLE-1133: -- Thanks [~vnick]. I haven't touched my Guacamole server in a while but will venture to give this a try! > VNC fails to connect to macOS > - > > Key: GUACAMOLE-1133 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1133 > Project: Guacamole > Issue Type: Bug > Components: guacamole >Affects Versions: 1.2.0 > Environment: Remote host macOS 10.15.5 > Guacamole server Raspbian GNU/Linux 10 >Reporter: Matt Fusfield >Assignee: Nick Couchman >Priority: Minor > > Since upgrading to version 1.2.0, I am unable to connect via VNC to a Mac > host. The same exact configuration works with 1.1.0. > > In syslog, there are entries regarding "Selecting security type 30" and then > it receives back types 33, 36,2,35. Then "VNC connection failed: > authentication or authorization failure" > > I attempted to change config to use mac username and password, and that did > not work either (on 1.1.0 the password is set to the Mac VNC password) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GUACAMOLE-1060) Client Body Size Limit in NGINX
[ https://issues.apache.org/jira/browse/GUACAMOLE-1060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman reassigned GUACAMOLE-1060: Assignee: Nick Couchman > Client Body Size Limit in NGINX > --- > > Key: GUACAMOLE-1060 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1060 > Project: Guacamole > Issue Type: Improvement > Components: Documentation >Reporter: Roman Bäriswyl >Assignee: Nick Couchman >Priority: Minor > > While trying to get the RDP file transfer working, I mostly got the error > "you do not have permission to upload this file" while uploading a file. I > then found out that files below 1 mb worked and larger ones not. > As I am using an nginx reverse proxy, this is because the default of > `client_max_body_size` is set to 1mb. > So it should be set higher or even indefinite (0). > I think this should be added to the example nginx configuration in `Chapter > 4. Proxying Guacamole`. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-604) Add support for Polish keyboard layout
[ https://issues.apache.org/jira/browse/GUACAMOLE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255993#comment-17255993 ] Szymon Porwolik commented on GUACAMOLE-604: --- The polish layout is described at: [http://kbdlayout.info/kbdpl1] With the following mapping: [http://kbdlayout.info/kbdpl1/download/klc] > Add support for Polish keyboard layout > -- > > Key: GUACAMOLE-604 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-604 > Project: Guacamole > Issue Type: New Feature > Components: RDP >Reporter: krogac >Priority: Minor > > Connection RDP not support Polish keyboard layout. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GUACAMOLE-925) Add Russian keyboard support for RDP
[ https://issues.apache.org/jira/browse/GUACAMOLE-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] NFisher updated GUACAMOLE-925: -- Attachment: (was: ru_ru_qwerty.keymap) > Add Russian keyboard support for RDP > > > Key: GUACAMOLE-925 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-925 > Project: Guacamole > Issue Type: Improvement > Components: RDP >Affects Versions: 1.0.0 >Reporter: Roman Adyev >Priority: Minor > Attachments: SCREEN.jpg, apache_guacamole_Russian_layouts.txt, > ru_ru_qwerty.keymap > > > Hello, dear support team! > I'm using Unicode layout because Russian layout isn't presented there, but > with Unicode layout I can't send keyboard shortcuts to remote RDP machine > (CTRL + C for example). > If I switch Unicode to English layout in connection settings, I can do > keyboard shortcuts but unfortunately some signs doesn't match when I use RU > layout, for example instead of period sign I got Russian letter "ю". > The keyboard layouts on remote and local machine are identical, that's 100%, > tested many times on different clean windows 10 installs, on work, on VMs, on > friend's PCs, etc. The issue always the same. > As I can see Russian layout isn't presented in Guacamole connection settings > by itself so it would be highly appreciated if you can suggest any workaround > for Russian users. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GUACAMOLE-925) Add Russian keyboard support for RDP
[ https://issues.apache.org/jira/browse/GUACAMOLE-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] NFisher updated GUACAMOLE-925: -- Attachment: ru_ru_qwerty.keymap > Add Russian keyboard support for RDP > > > Key: GUACAMOLE-925 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-925 > Project: Guacamole > Issue Type: Improvement > Components: RDP >Affects Versions: 1.0.0 >Reporter: Roman Adyev >Priority: Minor > Attachments: SCREEN.jpg, apache_guacamole_Russian_layouts.txt, > ru_ru_qwerty.keymap > > > Hello, dear support team! > I'm using Unicode layout because Russian layout isn't presented there, but > with Unicode layout I can't send keyboard shortcuts to remote RDP machine > (CTRL + C for example). > If I switch Unicode to English layout in connection settings, I can do > keyboard shortcuts but unfortunately some signs doesn't match when I use RU > layout, for example instead of period sign I got Russian letter "ю". > The keyboard layouts on remote and local machine are identical, that's 100%, > tested many times on different clean windows 10 installs, on work, on VMs, on > friend's PCs, etc. The issue always the same. > As I can see Russian layout isn't presented in Guacamole connection settings > by itself so it would be highly appreciated if you can suggest any workaround > for Russian users. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GUACAMOLE-925) Add Russian keyboard support for RDP
[
https://issues.apache.org/jira/browse/GUACAMOLE-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255868#comment-17255868
]
NFisher edited comment on GUACAMOLE-925 at 12/29/20, 8:38 AM:
--
I've added "ru_ru_qwerty.keymap" to attachments.
It is made on the basis of
"guacamole-server-1.2.0/src/protocols/rdp/keymaps/en_us_qwerty.keymap"
I'm unaware if double quotes (") and backslash ('\') should be escaped.
In "en_us" keymap they are not. I didn't escape them in "ru_ru" too.
To whom who can - please submit a pull request.
was (Author: nfisher):
I've added "ru_ru_qwerty.keymap" to attachments.
It is made on the basis of
"guacamole-server-1.2.0/src/protocols/rdp/keymaps/en_us_qwerty.keymap"
I'm unaware if double quotes (") and backslash (\\) should be escaped.
In "en_us" keymap they are not. I didn't escape them in "ru_ru" too.
To whom who can - please submit a pull request.
> Add Russian keyboard support for RDP
>
>
> Key: GUACAMOLE-925
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-925
> Project: Guacamole
> Issue Type: Improvement
> Components: RDP
>Affects Versions: 1.0.0
>Reporter: Roman Adyev
>Priority: Minor
> Attachments: SCREEN.jpg, apache_guacamole_Russian_layouts.txt,
> ru_ru_qwerty.keymap
>
>
> Hello, dear support team!
> I'm using Unicode layout because Russian layout isn't presented there, but
> with Unicode layout I can't send keyboard shortcuts to remote RDP machine
> (CTRL + C for example).
> If I switch Unicode to English layout in connection settings, I can do
> keyboard shortcuts but unfortunately some signs doesn't match when I use RU
> layout, for example instead of period sign I got Russian letter "ю".
> The keyboard layouts on remote and local machine are identical, that's 100%,
> tested many times on different clean windows 10 installs, on work, on VMs, on
> friend's PCs, etc. The issue always the same.
> As I can see Russian layout isn't presented in Guacamole connection settings
> by itself so it would be highly appreciated if you can suggest any workaround
> for Russian users.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GUACAMOLE-925) Add Russian keyboard support for RDP
[
https://issues.apache.org/jira/browse/GUACAMOLE-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255868#comment-17255868
]
NFisher edited comment on GUACAMOLE-925 at 12/29/20, 8:38 AM:
--
I've added "ru_ru_qwerty.keymap" to attachments.
It is made on the basis of
"guacamole-server-1.2.0/src/protocols/rdp/keymaps/en_us_qwerty.keymap"
I'm unaware if double quotes (") and backslash (\\) should be escaped.
In "en_us" keymap they are not. I didn't escape them in "ru_ru" too.
To whom who can - please submit a pull request.
was (Author: nfisher):
I've added "ru_ru_qwerty.keymap" to attachments.
It is made on the basis of
"guacamole-server-1.2.0/src/protocols/rdp/keymaps/en_us_qwerty.keymap"
I'm unaware if double quotes (") and backslash (\) should be escaped.
In "en_us" keymap they are not. I didn't escape them in "ru_ru" too.
To whom who can - please submit a pull request.
> Add Russian keyboard support for RDP
>
>
> Key: GUACAMOLE-925
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-925
> Project: Guacamole
> Issue Type: Improvement
> Components: RDP
>Affects Versions: 1.0.0
>Reporter: Roman Adyev
>Priority: Minor
> Attachments: SCREEN.jpg, apache_guacamole_Russian_layouts.txt,
> ru_ru_qwerty.keymap
>
>
> Hello, dear support team!
> I'm using Unicode layout because Russian layout isn't presented there, but
> with Unicode layout I can't send keyboard shortcuts to remote RDP machine
> (CTRL + C for example).
> If I switch Unicode to English layout in connection settings, I can do
> keyboard shortcuts but unfortunately some signs doesn't match when I use RU
> layout, for example instead of period sign I got Russian letter "ю".
> The keyboard layouts on remote and local machine are identical, that's 100%,
> tested many times on different clean windows 10 installs, on work, on VMs, on
> friend's PCs, etc. The issue always the same.
> As I can see Russian layout isn't presented in Guacamole connection settings
> by itself so it would be highly appreciated if you can suggest any workaround
> for Russian users.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GUACAMOLE-925) Add Russian keyboard support for RDP
[
https://issues.apache.org/jira/browse/GUACAMOLE-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255868#comment-17255868
]
NFisher edited comment on GUACAMOLE-925 at 12/29/20, 8:38 AM:
--
I've added "ru_ru_qwerty.keymap" to attachments.
It is made on the basis of
"guacamole-server-1.2.0/src/protocols/rdp/keymaps/en_us_qwerty.keymap"
I'm unaware if double quotes ('"') and backslash ('\') should be escaped.
In "en_us" keymap they are not. I didn't escape them in "ru_ru" too.
To whom who can - please submit a pull request.
was (Author: nfisher):
I've added "ru_ru_qwerty.keymap" to attachments.
It is made on the basis of
"guacamole-server-1.2.0/src/protocols/rdp/keymaps/en_us_qwerty.keymap"
I'm unaware if double quotes (") and backslash ('\') should be escaped.
In "en_us" keymap they are not. I didn't escape them in "ru_ru" too.
To whom who can - please submit a pull request.
> Add Russian keyboard support for RDP
>
>
> Key: GUACAMOLE-925
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-925
> Project: Guacamole
> Issue Type: Improvement
> Components: RDP
>Affects Versions: 1.0.0
>Reporter: Roman Adyev
>Priority: Minor
> Attachments: SCREEN.jpg, apache_guacamole_Russian_layouts.txt,
> ru_ru_qwerty.keymap
>
>
> Hello, dear support team!
> I'm using Unicode layout because Russian layout isn't presented there, but
> with Unicode layout I can't send keyboard shortcuts to remote RDP machine
> (CTRL + C for example).
> If I switch Unicode to English layout in connection settings, I can do
> keyboard shortcuts but unfortunately some signs doesn't match when I use RU
> layout, for example instead of period sign I got Russian letter "ю".
> The keyboard layouts on remote and local machine are identical, that's 100%,
> tested many times on different clean windows 10 installs, on work, on VMs, on
> friend's PCs, etc. The issue always the same.
> As I can see Russian layout isn't presented in Guacamole connection settings
> by itself so it would be highly appreciated if you can suggest any workaround
> for Russian users.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-925) Add Russian keyboard support for RDP
[
https://issues.apache.org/jira/browse/GUACAMOLE-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255868#comment-17255868
]
NFisher commented on GUACAMOLE-925:
---
I've added "ru_ru_qwerty.keymap" to attachments.
It is made on the basis of
"guacamole-server-1.2.0/src/protocols/rdp/keymaps/en_us_qwerty.keymap"
I'm unaware if double quotes (") and backslash (\) should be escaped.
In "en_us" keymap they are not. I didn't escape them in "ru_ru" too.
To whom who can - please submit a pull request.
> Add Russian keyboard support for RDP
>
>
> Key: GUACAMOLE-925
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-925
> Project: Guacamole
> Issue Type: Improvement
> Components: RDP
>Affects Versions: 1.0.0
>Reporter: Roman Adyev
>Priority: Minor
> Attachments: SCREEN.jpg, apache_guacamole_Russian_layouts.txt,
> ru_ru_qwerty.keymap
>
>
> Hello, dear support team!
> I'm using Unicode layout because Russian layout isn't presented there, but
> with Unicode layout I can't send keyboard shortcuts to remote RDP machine
> (CTRL + C for example).
> If I switch Unicode to English layout in connection settings, I can do
> keyboard shortcuts but unfortunately some signs doesn't match when I use RU
> layout, for example instead of period sign I got Russian letter "ю".
> The keyboard layouts on remote and local machine are identical, that's 100%,
> tested many times on different clean windows 10 installs, on work, on VMs, on
> friend's PCs, etc. The issue always the same.
> As I can see Russian layout isn't presented in Guacamole connection settings
> by itself so it would be highly appreciated if you can suggest any workaround
> for Russian users.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GUACAMOLE-925) Add Russian keyboard support for RDP
[ https://issues.apache.org/jira/browse/GUACAMOLE-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] NFisher updated GUACAMOLE-925: -- Attachment: ru_ru_qwerty.keymap > Add Russian keyboard support for RDP > > > Key: GUACAMOLE-925 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-925 > Project: Guacamole > Issue Type: Improvement > Components: RDP >Affects Versions: 1.0.0 >Reporter: Roman Adyev >Priority: Minor > Attachments: SCREEN.jpg, apache_guacamole_Russian_layouts.txt, > ru_ru_qwerty.keymap > > > Hello, dear support team! > I'm using Unicode layout because Russian layout isn't presented there, but > with Unicode layout I can't send keyboard shortcuts to remote RDP machine > (CTRL + C for example). > If I switch Unicode to English layout in connection settings, I can do > keyboard shortcuts but unfortunately some signs doesn't match when I use RU > layout, for example instead of period sign I got Russian letter "ю". > The keyboard layouts on remote and local machine are identical, that's 100%, > tested many times on different clean windows 10 installs, on work, on VMs, on > friend's PCs, etc. The issue always the same. > As I can see Russian layout isn't presented in Guacamole connection settings > by itself so it would be highly appreciated if you can suggest any workaround > for Russian users. -- This message was sent by Atlassian Jira (v8.3.4#803005)
