Hello,
I am writing to report a persistent issue regarding the use of
user-specific SSH private keys with the JDBC authentication extension
in Apache Guacamole (version 1.5.0, running via the latest Docker
images).
My objective is to configure a shared SSH connection that utilizes
nominative keys, with each user's private key stored as a private-key
attribute in the guacamole_user_attribute table (MariaDB backend). The
expected behavior is that Guacamole would utilize this user-specific
attribute when the connection's primary "Private Key" parameter is
left blank.
This standard mechanism, however, is not functioning. Our DEBUG logs
from guacd confirm that when using this standard inheritance method,
no private key is ever transmitted to the daemon; the connection
defaults to password authentication. We have validated that the key
itself (a standard, unencrypted traditional RSA PEM, -----BEGIN RSA
PRIVATE KEY-----) is correct and functions perfectly via a standard
SSH terminal client.
To bypass this apparent inheritance failure, we attempted to force the
attribute retrieval by using the Expression Language (EL) variable
${#user.private-key} directly in the connection's "Private Key"
parameter field. This test yielded partial success: the guacd logs
confirmed that a key was received (Auth key successfully imported).
However, the authentication immediately failed with the error: Public
key authentication failed: Unable to extract public key from private
key file: Unsupported private key file format. This same error
occurred regardless of whether the key stored in the database was in
traditional RSA PEM or PKCS#8 format.
The critical diagnostic step was as follows: we copied the identical
RSA PEM key string from the database (the one failing via EL) and
pasted it directly into the connection's "Private Key" parameter field
in the Guacamole UI. When configured this way, the connection
succeeded instantly.
This leads us to a clear conclusion: our installation appears to have
two distinct issues. First, the standard JDBC attribute inheritance
for private-key is non-functional. Second, while the EL expression
${#user.private-key} can retrieve the attribute, it appears to corrupt
the formatting (presumably newlines or encoding) of the multi-line key
string during transmission, rendering it unusable by libssh2.
This combination makes it impossible to implement our desired
architecture of shared connections with nominative, database-stored
keys. We would be grateful if the community could confirm if this is a
known issue, or if there is an alternative configuration we may have
overlooked.
Thank you.
Théo
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
