Menu

SSH with private-key and NO password/passphrase

Help
2014-09-18
2014-09-19
  • Ben Coleman

    Ben Coleman - 2014-09-18

    I'm trying to set up a connection to a number of hosts that require SSH private keyfile authentication.

    There is no password (obviously as it's using a keyfile) and no passphrase on the keyfile

    I've put my private-key in the user-mapping file and put blank password & passphrase in there too, but when I try to connect I get prompted for a password, which should not happen. When I put anything into the password it fails to connect

    How can I fix this?
    And where is any of this logged, where can I go to see the details of the SSH authentication errors?

    Thanks

     
  • Ben Coleman

    Ben Coleman - 2014-09-18

    It's also very unclear the format of the private-key parameter. My key file starts with "-----BEGIN RSA PRIVATE KEY-----" and equivalent footer, is this to be included?
    My keyfile is also split over several lines? Should it be flattened to a single line?

    Some examples in the documentation would really help

     
  • Michael Jumper

    Michael Jumper - 2014-09-18

    Yes, you must include the entire file contents, including the header and footer. The SSH support actually looks at these headers to determine the type of key.

    It's fine that there are multiple lines - that's expected. Just be sure to include the entire contents of the private key file, verbatim, unchanged, as the contents of the parameter.

    If the contents of "private-key" appear completely invalid, it will still try to load the key, under the assumption that it needs a key passphrase to continue. If the passphrase given doesn't help, you'll see the following error in syslog:

    ERROR: Auth key import failed.

     
    • Ben Coleman

      Ben Coleman - 2014-09-19

      Thanks for the reply
      I've put the whole of my key file in there and I still get a password prompt (I shouldn't) and it still fails to connect.

      I've tested it with a server where I changed the SSH config to allow passwords and Guacamole works fine and connects - but this is insecure and not permitted in this environment

      There are no errors in syslog, just this
      Sep 19 07:29:05 guacamole guacd[9386]: Protocol "ssh" selected
      Sep 19 07:29:05 guacamole guacd[9386]: Starting client
      Sep 19 07:29:11 guacamole guacd[9386]: Client instruction handler error: Success
      Sep 19 07:29:11 guacamole guacd[9386]: Failing instruction handler in client was "disconnect"
      Sep 19 07:29:12 guacamole guacd[9386]: Client finished normally

      Why is it still prompting for a password, when a private-key is present?
      Where can I see the errors, the info in syslog seems very basic, I need debug level info

      Thanks

       
  • Michael Jumper

    Michael Jumper - 2014-09-19

    It sounds like the version of guacamole-server installed doesn't have private key support.

    If "private-key" is specified, the only prompt you will ever see reads "Key passphrase:", not "Password:". If you see a password prompt, then the "private-key" parameter is being ignored, which would only happen if support is absent.

    What version of guacamole-server is present? Did you build from source?

     
  • Ben Coleman

    Ben Coleman - 2014-09-19

    Damn you're right! I feel silly
    I installed from packages on Ubuntu 14.04, and the login screen says 0.8.3.

    For some reason I thought the package method would install the latest version

     
  • Ben Coleman

    Ben Coleman - 2014-09-19

    Hi
    I've compiled 0.9.2 from source and it's working fine now. Thanks a lot!

    One thing I've noticed - your LDAP schema defines an entry for guacConfigParamer as a string, so it's truncated at 255 bytes - which means it fails when I have guacamole configured with LDAP as you can store a private-key in the attribute. It's fine when using the user-mapping.xml
    You might want to revise your LDAP schema

     
  • Michael Jumper

    Michael Jumper - 2014-09-19

    Yes, the schema is definitely behind the times, though I'd rather handle this through decoupling auth from storage: https://glyptodon.org/jira/browse/GUAC-586

    It made sense a years ago to store connection information along with auth depending on the mechanism was in use, but we've grown beyond that. There's no reason LDAP (or XML, or MySQL) should be completely tied to their own internal storage.