Support for ed25519

[ju29ro14]

We want to upgrade or SSH keys from RSA to ED25519 and this is not possible at the moment. When we try to update the Key or even to create a new profile and add a new Key, ED25519 ia not a valid one.

Question : If we upgrade to the latest version available (3.09.00) is ED25519 supported ? And if not, will it be available in the future ?

If there is a way to disable PubKey validation, it is fine for us. However we would also need the MasterKey to be ed25519.

[borisbastille]

Hello, a client of mine is hit with this too, he has been asked to enforce his security according to the latest recommendations and is required to use ed25519:

• https://blog.g3rt.nl/upgrade-your-ssh-keys.html
• https://www.benhup.com/freebsd/openssh-configuration-with-elliptic-curve/
• https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Security

Right now, he can't comply to that request since the whole key management of the infrastructure depends on Bastillion.

Regardless of what library/third-party component Bastillion uses to validate the keys, the validation itself could be some option in the configuration : for serious administrators who use this software for key-management only and make sure that the keys are correct anyway, it doesn't really make sense to be blocked by a functionality that is trying to do their job and failing at it :-)

I think this would not require a lot of effort since it only means :

• adding a configuration option like KEY_VALIDATION that could be set to
  • always for activating it globally (current behavior, which would remain the default)
  • never for disabling it globally
  • system for activating it on a per-system basis (that would require some more work though, in the DB record of a host: no for disabled, yes for enabled, NULL if unset, the default being yes if unset)
• add a check at the beginning of the validation function that returns True if the validation is disabled in the current context

Do you think we can expect at least always and never to be implemented in the next release ?

That would solve the current situation and since more and more people will need to upgrade their keys in the near future, that would give the team more time to transition to a more modern solution for the key validation.

I would love to implement it myself and make a pull request, but I'm not into the Java world and it would take me much more time to get everything working than to some experienced Bastillion developer, and since I don't have that time right now I'll have to pass ,-(

Thanks for your great work ! Boris

[ju29ro14]

i have nothing to add to @borisbastille comment and hope that Bastillion developers will implement this suggestion/request in the next release, it will solve my issue and also future issues since more people will need it and will request it.

Thank you

[mcp11]

+1 from me. Everywhere you read how rsa-2048 is not holding up anymore today and you should switch to longer keylengths or even better to more modern algorithms like ed25519, so I would love to see it supported by bastillion or at least I would like to see the option of disabling the key checking like @borisbastille suggested.

Right now this issue is the only thing holding me back from buying a bastillion license

[ixrjog]

    <dependency>
        <groupId>net.i2p.crypto</groupId>
        <artifactId>eddsa</artifactId>
        <version>0.3.0</version>
    </dependency>

[qdrddr]

+1