Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ecdsa-sha2-nistp384 and ecdsa-sha2-nistp521 key authentication #611

Closed
wants to merge 8 commits into from

Conversation

@mchlt
Copy link

@mchlt mchlt commented Nov 5, 2015

Added ecdsa-sha2-nistp384 and ecdsa-sha2-nistp521 key authentication support.
Didn't have to change too much. The ecdsa module already supported them, so just needed a little work to get the right ssh parameters into ECDSAKey and having it use ecdsa's features for identifying which key size is being used.
Added bits parameter to ecdsa generate function to make it compatible with RSAKey and DSSKey. Because of this, I could easily add ecdsa to demo_keygen.py.

Tested client login against all key sizes, added ecdsa t demo.py.
Generating ecdsa 256, 384 and 521 size keys works with demo_keygen.py
Existing tests for ecdsa-sha2-nistp256 all still work fine without modification.

@bitprophet
Copy link
Member

@bitprophet bitprophet commented Nov 6, 2015

Thanks for this. Seems like it includes the changes from #610 too? If so, you can close #610, I don't actually mind "multi-change" PRs if the 2nd change is just in the demo folder :)

Loading

…efore lacked the new diffie-hellman-group-exchange-sha256 kex
@mchlt
Copy link
Author

@mchlt mchlt commented Nov 22, 2015

I've added a fix to transport.py where in the case of GSS, the key exchange algorithm list was replaced further on in the code, which has caused a later update which added diffie-hellman-group-exchange-sha256to be forgotten in that location. Moved the GSS preferred kex list to the top for consistency

Loading

mchlt added 2 commits Nov 22, 2015
…efore lacked the new diffie-hellman-group-exchange-sha256 kex
@bitprophet
Copy link
Member

@bitprophet bitprophet commented Apr 24, 2016

We're planning to merge #394 into master soon and that'll make it hard to merge this as-is. Pretty sure it'd be possible to take the general approach in here and apply it to the updated ecdsakey.py afterwards; I'm going to bump this to a 2.1 milestone with that in mind. (If @mchlt finds time to make this #394-friendly before 2.0 releases, I can make it part of 2.0, doesn't matter a ton to me either way.)

Loading

@CrazyCasta
Copy link
Contributor

@CrazyCasta CrazyCasta commented Apr 25, 2016

I'm going to have a version of my pull request done soon. Should I link that here or what?

Loading

@CrazyCasta
Copy link
Contributor

@CrazyCasta CrazyCasta commented Apr 25, 2016

Ok, I've updated my PR, now #731.

A quick overview of how mine differs from mchlt's:

  • I have some wrappers around my definitions of the various curves, should make it easier to add more in the future if we ever want that.
  • Added tests to test all the new stuff.
  • I didn't bother with the demo stuff. I just want this in by 2.0 so I can stop using my own branch of paramiko.
  • I'm not familiar enough with GSSAPI/Kerberos to know what I'm doing wrt making the gss_ keys, so I just left that out for now.

Loading

@bitprophet
Copy link
Member

@bitprophet bitprophet commented Apr 26, 2016

Close to merging #731. I'd ideally like the demos to get updated too but it can wait for a bugfix or similar update once someone else has the time :)

EDIT: re: the GSS key stuff, from my reading that was simply a cleanup/format change on @mchlt's part and actually orthogonal to the ECDSA functionality update. So again, not a blocker AFAICT.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants