Karaf
  1. Karaf
  2. KARAF-32

Support ssh public key authentication and agent forwarding

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.2.6, 3.0.0
    • Component/s: karaf-shell
    • Labels:
      None

      Description

      The karaf agent needs to be enhanced to be able to set up an ssh agent and use a public/private key.
      The ssh server need to be configured with a public key authentication that could delegate to the KeystoreInstance using certificates.
      The goal would be support the following use cases:

      • once a user is logged into a given karaf instance, he can connect to any other instance (provided that the public key is supported)
      • the stop script could use the ssh agent so that you don't need to launch it with a password on the command line

      A set of commands to administer the keystores might be interesting (maybe a console plugin too, but we need to check with what Geronimo provides in this area).

      Btw, I wonder if Apache Shiro would help in any way for all the security stuff.

        Issue Links

          Activity

          Hide
          Les Hazlewood added a comment -

          Hi Guillaume - feel free to ask any questions on the Shiro mailing lists if necessary. We'll do what we can to help.

          Show
          Les Hazlewood added a comment - Hi Guillaume - feel free to ask any questions on the Shiro mailing lists if necessary. We'll do what we can to help.
          Hide
          Guillaume Nodet added a comment -

          We need a set of login modules to support certificate based authentication.

          Show
          Guillaume Nodet added a comment - We need a set of login modules to support certificate based authentication.
          Hide
          Wolfgang Glas added a comment -

          This patch against karaf-2.2.5 introduces public key authentication to org.apache.karaf.shell.ssh. Unfortunately, it triggers an erro inside the blueprint implementation of aries-0.3.1 when cconverting a doubly-nested generic of type java.util.List<org.apache.sshd.common.NamedFactory<org.apache.sshd.server.UserAuth>>.

          Commenting out the setter of userAuthFactories makes the thing work, but the server announces password authentication even when is has been tuned of by the new config option 'authMethods'.

          Please help me to further work out this stuff.

          TIA and best regards, Wolfgang

          Show
          Wolfgang Glas added a comment - This patch against karaf-2.2.5 introduces public key authentication to org.apache.karaf.shell.ssh. Unfortunately, it triggers an erro inside the blueprint implementation of aries-0.3.1 when cconverting a doubly-nested generic of type java.util.List<org.apache.sshd.common.NamedFactory<org.apache.sshd.server.UserAuth>>. Commenting out the setter of userAuthFactories makes the thing work, but the server announces password authentication even when is has been tuned of by the new config option 'authMethods'. Please help me to further work out this stuff. TIA and best regards, Wolfgang
          Hide
          Jean-Baptiste Onofré added a comment -

          Hi Wolfgang,

          thanks for the contribution, I will review/fix it.

          Regards
          JB

          Show
          Jean-Baptiste Onofré added a comment - Hi Wolfgang, thanks for the contribution, I will review/fix it. Regards JB
          Hide
          Wolfgang Glas added a comment -

          Hello Jean-Baptiste,

          Thanks for your reply,

          I'd really appreciate to work this out together and bring it to karaf's mainline.

          Regards, Wolfgang

          Show
          Wolfgang Glas added a comment - Hello Jean-Baptiste, Thanks for your reply, I'd really appreciate to work this out together and bring it to karaf's mainline. Regards, Wolfgang
          Hide
          Guillaume Nodet added a comment -

          Thx for this patch. Note that the blueprint problem isn't really a bug. It's a limitation. So there's no way to expect a solution from the blueprint container.
          One way around is to define an explicit converter in the xml which will allow the conversion, even if no real change is made on the data.

          Show
          Guillaume Nodet added a comment - Thx for this patch. Note that the blueprint problem isn't really a bug. It's a limitation. So there's no way to expect a solution from the blueprint container. One way around is to define an explicit converter in the xml which will allow the conversion, even if no real change is made on the data.
          Hide
          Wolfgang Glas added a comment -

          Guillaume,

          ThX for your feedback.

          Could you please describe the mentioned limitation in more detail.

          These are the error messages I received in my log file:

          ************************
          org.osgi.service.blueprint.container.ComponentDefinitionException: Error setting property: PropertyDescriptor <name: userAuthFactories, getter: public java.util.List org.apache.sshd.SshServer.getUserAuthFactories(), setter: [public void org.apache.sshd.SshServer.setUserAuthFactories(java.util.List)]
          Caused by: java.lang.Exception: Unable to convert from [org.apache.sshd.server.auth.UserAuthPublicKey$Factory@78bdf2a] to java.util.List<org.apache.sshd.common.NamedFactory<org.apache.sshd.server.UserAuth>>(error converting collection entry)
          Caused by: java.lang.Exception: Unable to convert value org.apache.sshd.server.auth.UserAuthPublicKey$Factory@78bdf2a to type org.apache.sshd.common.NamedFactory<org.apache.sshd.server.UserAuth>

          ************************

          AFAICS, the inner Factory class of UserAuthPublicKey implements NamedFactory<UserAuth>, so there should be no problem with isAssignableFrom() and friends...

          Is the limitation due to the fact, that the generic is doubly nested in this case?
          Or are the other limitations?

          TIA, Wolfgang

          Show
          Wolfgang Glas added a comment - Guillaume, ThX for your feedback. Could you please describe the mentioned limitation in more detail. These are the error messages I received in my log file: ************************ org.osgi.service.blueprint.container.ComponentDefinitionException: Error setting property: PropertyDescriptor <name: userAuthFactories, getter: public java.util.List org.apache.sshd.SshServer.getUserAuthFactories(), setter: [public void org.apache.sshd.SshServer.setUserAuthFactories(java.util.List)] Caused by: java.lang.Exception: Unable to convert from [org.apache.sshd.server.auth.UserAuthPublicKey$Factory@78bdf2a] to java.util.List<org.apache.sshd.common.NamedFactory<org.apache.sshd.server.UserAuth>>(error converting collection entry) Caused by: java.lang.Exception: Unable to convert value org.apache.sshd.server.auth.UserAuthPublicKey$Factory@78bdf2a to type org.apache.sshd.common.NamedFactory<org.apache.sshd.server.UserAuth> ************************ AFAICS, the inner Factory class of UserAuthPublicKey implements NamedFactory<UserAuth>, so there should be no problem with isAssignableFrom() and friends... Is the limitation due to the fact, that the generic is doubly nested in this case? Or are the other limitations? TIA, Wolfgang
          Hide
          Guillaume Nodet added a comment -

          The limitation is that when you have a collection object, there's no way to know the generic type because this information is only available on method arguments through reflection, not object instances.
          So the conversion mechanism is explicitly asked to fail in such case. The solution is either to change the code to avoid such conversion or use a blueprint converter to handle that. We have examples of using such converters in ShellFactoryImpl (in shell/ssh) or PropertiesConverter (in jaas/modules).

          Show
          Guillaume Nodet added a comment - The limitation is that when you have a collection object, there's no way to know the generic type because this information is only available on method arguments through reflection, not object instances. So the conversion mechanism is explicitly asked to fail in such case. The solution is either to change the code to avoid such conversion or use a blueprint converter to handle that. We have examples of using such converters in ShellFactoryImpl (in shell/ssh) or PropertiesConverter (in jaas/modules).
          Hide
          Wolfgang Glas added a comment -

          With the kind help of Guillaume, I now figured out to introduce a typ converter, which now allows to correctly announce the configured auth methods on the wire.

          Show
          Wolfgang Glas added a comment - With the kind help of Guillaume, I now figured out to introduce a typ converter, which now allows to correctly announce the configured auth methods on the wire.
          Hide
          Wolfgang Glas added a comment -

          OK, my version is now working. Another question concerns watching for authorized_keys changes. I implemented a minute-timer in my patch, but I think there should be a better solution. Is there something like a directory or file watcher inside the karaf universe, which makes my timer-based approach obsolete?

          Show
          Wolfgang Glas added a comment - OK, my version is now working. Another question concerns watching for authorized_keys changes. I implemented a minute-timer in my patch, but I think there should be a better solution. Is there something like a directory or file watcher inside the karaf universe, which makes my timer-based approach obsolete?
          Hide
          Achim Nierbeck added a comment -

          One can use the FileInstaller-Service for watching for certain files, like is done with the different deployers and also with the config file importers. You might take a look at it if it is sufficient for you

          Show
          Achim Nierbeck added a comment - One can use the FileInstaller-Service for watching for certain files, like is done with the different deployers and also with the config file importers. You might take a look at it if it is sufficient for you
          Hide
          Guillaume Nodet added a comment -

          Why not checking the last modified date of the file and reload if needed when the authentication is performed. I'd go even further and reload each time as done with the JAAS realm. I don't really think it's a problem given karat is not really meant to receive thousands of ssh connections.

          Show
          Guillaume Nodet added a comment - Why not checking the last modified date of the file and reload if needed when the authentication is performed. I'd go even further and reload each time as done with the JAAS realm. I don't really think it's a problem given karat is not really meant to receive thousands of ssh connections.
          Hide
          Wolfgang Glas added a comment -

          A fileinstall-based version of my path is include. It has the drawback, tahta you have to modify fileinstall.filters von config.properties and that the install(File) is not called, when the bundle is restarted.

          I think I will end up with what Gullaume has suggested. Less dependencies, clear semantics, easy to read.

          Show
          Wolfgang Glas added a comment - A fileinstall-based version of my path is include. It has the drawback, tahta you have to modify fileinstall.filters von config.properties and that the install(File) is not called, when the bundle is restarted. I think I will end up with what Gullaume has suggested. Less dependencies, clear semantics, easy to read.
          Hide
          Wolfgang Glas added a comment -

          Yet another version, which does a bare recheck for authorized_keys in authenticate() as supposed by Guillaume. This is really my preferred version and the one I'd like to be further reviewed and applied to karaf's trunk.

          Regards, Wolfgang

          Show
          Wolfgang Glas added a comment - Yet another version, which does a bare recheck for authorized_keys in authenticate() as supposed by Guillaume. This is really my preferred version and the one I'd like to be further reviewed and applied to karaf's trunk. Regards, Wolfgang
          Hide
          Wolfgang Glas added a comment -

          Hi Jean-Baptiste,

          Did you have time to review my patches any eventually commit them to karaf's trunk in the meanwhile?

          Best regards, Wolfgang

          Show
          Wolfgang Glas added a comment - Hi Jean-Baptiste, Did you have time to review my patches any eventually commit them to karaf's trunk in the meanwhile? Best regards, Wolfgang
          Hide
          Jean-Baptiste Onofré added a comment -

          Thanks for the reminder Wolfgang. I will review it to try to include it in the next Karaf release.

          Show
          Jean-Baptiste Onofré added a comment - Thanks for the reminder Wolfgang. I will review it to try to include it in the next Karaf release.
          Hide
          Wolfgang Glas added a comment -

          Hi Jean-Baptiste,

          Thanks for applying, please note, that the original issue description includes more things like agent integration et al. Maybe it would be benefitial to open some followup issues for the agent integration issues?

          Issues with a smaller set of features may help to tackle the problem step-by-step and encourage other developers to send in smaller patches, like I've done.

          Best regards,

          Wolfgang

          Show
          Wolfgang Glas added a comment - Hi Jean-Baptiste, Thanks for applying, please note, that the original issue description includes more things like agent integration et al. Maybe it would be benefitial to open some followup issues for the agent integration issues? Issues with a smaller set of features may help to tackle the problem step-by-step and encourage other developers to send in smaller patches, like I've done. Best regards, Wolfgang
          Hide
          Jean-Baptiste Onofré added a comment -

          It makes sense, I will review the patches and apply for next 2.2.6 (and trunk). I will raise new issues as well.

          Show
          Jean-Baptiste Onofré added a comment - It makes sense, I will review the patches and apply for next 2.2.6 (and trunk). I will raise new issues as well.
          Hide
          Achim Nierbeck added a comment -

          what's the status of this?
          @JB are you done with reviewing? I think we should either fix it or bump it if it needs more reviewing

          Show
          Achim Nierbeck added a comment - what's the status of this? @JB are you done with reviewing? I think we should either fix it or bump it if it needs more reviewing
          Hide
          Wolfgang Glas added a comment -

          Jean-Baptise,

          Now that the issue is closed could you please sum up, which version has actually been applied to trunk and which followup issues have been raised?

          TIA, Wolfgang

          Show
          Wolfgang Glas added a comment - Jean-Baptise, Now that the issue is closed could you please sum up, which version has actually been applied to trunk and which followup issues have been raised? TIA, Wolfgang
          Hide
          Hendy Irawan added a comment -

          Is this working on 2.3.0-SNAPSHOT ?

          How to use it ?

          Show
          Hendy Irawan added a comment - Is this working on 2.3.0-SNAPSHOT ? How to use it ?
          Hide
          Hendy Irawan added a comment -

          Hey! It works! Tested with 2.3.0-SNAPSHOT.

          For those wondering, create $

          {karaf.home}

          /etc/keys.properties with the following format :

          # username=<public key>,<roles...>
          admin=AAAAB3NzaC1yc2EA......XLQ==,admin
          

          I looked up the keys.properties format from karaf trunk (3.0.0-SNAPSHOT)

          Now you can just ssh admin@hostname and no password. Wonderful !!!

          Show
          Hendy Irawan added a comment - Hey! It works! Tested with 2.3.0-SNAPSHOT. For those wondering, create $ {karaf.home} /etc/keys.properties with the following format : # username=< public key>,<roles...> admin=AAAAB3NzaC1yc2EA......XLQ==,admin I looked up the keys.properties format from karaf trunk (3.0.0-SNAPSHOT) Now you can just ssh admin@hostname and no password. Wonderful !!!
          Show
          Hendy Irawan added a comment - useful thread: http://karaf.922171.n3.nabble.com/HEADS-UP-Ssh-agent-and-key-authentication-support-td4000734.html
          Hide
          Hendy Irawan added a comment -

          Verrrryy Nice feature: You can specify multiple keys for one user, just specify multiple lines for that user! )) THANKS GUYS!

          Show
          Hendy Irawan added a comment - Verrrryy Nice feature: You can specify multiple keys for one user, just specify multiple lines for that user! )) THANKS GUYS!
          Hide
          Hendy Irawan added a comment -

          I spoke too soon, it doesn't support multiple keys

          Show
          Hendy Irawan added a comment - I spoke too soon, it doesn't support multiple keys

            People

            • Assignee:
              Jean-Baptiste Onofré
              Reporter:
              Guillaume Nodet
            • Votes:
              2 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development