FAQ
I'm writing an application that uses and generates SSH keys on demand, and
I want to export these for use by other applications (ssh -i, ssh-agent
add, etc..)

Currently I've patched my local go.crypto/ssh library to make
serializePublickey a public function (ie, SerializePublickey), This is
useful for export by calling SerializePublicKey(&key), then encoding with
base64.StdEncoding.EncodeToString. On the server side, the key bytes in
PublicKeysCallback in ssh.ServerConfig are returned in this format as well,
so any keys used for the server would use need SerializePublickey as well
(for comparison)

Is there any other way of doing this without reproducing the entire
marshaling scheme currently in the ssh package? Making the
serializePublickey function public seems to be the easiest path -- would it
make sense to change the visibility of the function in the ssh library to
allow this in the current design? I didn't see anything in the archives
about others doing similar things with SSH keys.

-sml

--

Search Discussions

  • Dave Cheney at Nov 20, 2012 at 11:04 pm
    Possibly these functions should move to their own package. I think there may be an issue similar to this in the issue tracker already.

    Agl, thoughts?
    On 21/11/2012, at 7:49, sledbetter@google.com wrote:

    I'm writing an application that uses and generates SSH keys on demand, and I want to export these for use by other applications (ssh -i, ssh-agent add, etc..)

    Currently I've patched my local go.crypto/ssh library to make serializePublickey a public function (ie, SerializePublickey), This is useful for export by calling SerializePublicKey(&key), then encoding with base64.StdEncoding.EncodeToString. On the server side, the key bytes in PublicKeysCallback in ssh.ServerConfig are returned in this format as well, so any keys used for the server would use need SerializePublickey as well (for comparison)

    Is there any other way of doing this without reproducing the entire marshaling scheme currently in the ssh package? Making the serializePublickey function public seems to be the easiest path -- would it make sense to change the visibility of the function in the ssh library to allow this in the current design? I didn't see anything in the archives about others doing similar things with SSH keys.

    -sml
    --
    --
  • Adam Langley at Nov 20, 2012 at 10:42 pm

    On Tue, Nov 20, 2012 at 5:35 PM, Dave Cheney wrote:
    Possibly these functions should move to their own package. I think there may
    be an issue similar to this in the issue tracker already.

    Agl, thoughts?
    Yes, I believe this is the second such request.

    go.crypto/ssh/marshal?

    It would probably be a bit of an exercise to do the actual separation
    (and I'm not volunteering) but I've no fundamental objections.


    Cheers

    AGL

    --
  • Sledbetter at Nov 21, 2012 at 6:27 pm
    So I've taken a stab at moving all the wire-touching code into another
    package (go.crypto/ssh/wire) and am currently refactoring the code where I
    can -- I'll let you know my progress once its stable enough, possibly send
    out a CL or 2.

    -sml
    On Tuesday, November 20, 2012 2:42:25 PM UTC-8, agl wrote:
    On Tue, Nov 20, 2012 at 5:35 PM, Dave Cheney wrote:
    Possibly these functions should move to their own package. I think there may
    be an issue similar to this in the issue tracker already.

    Agl, thoughts?
    Yes, I believe this is the second such request.

    go.crypto/ssh/marshal?

    It would probably be a bit of an exercise to do the actual separation
    (and I'm not volunteering) but I've no fundamental objections.


    Cheers

    AGL
    --
  • Sledbetter at Nov 27, 2012 at 6:43 pm
    I have to agree its quite an exercise. Unfortunately I've not been very
    satisfied with any of the results of the various approaches I made over the
    past week. It seems that moving anything into another package with hope of
    using it internally and externally basically ends up with a scenario where
    anything the new package would need either gets a) exported by the ssh
    package, therefor exporting lots of internal functionality unnecessary for
    use other than by the wire package or b) pulled into the wire package,
    leaving the ssh package with just interfaces and a handful of functions
    that are essentially wrapped calls of the second package which really just
    should be in the second package, leaving you with one package again :P

    I'm back to the idea of exporting/wrapping the few unexported functions
    necessary to proceed (serializePublickey, parsePubKey for typical
    auth_keys/id_rsa.pub keys), and possibly renaming them to fit into the
    larger Marshal/Parse nomenclature of the other Go crypto packages.

    I've uploaded by changes to http://codereview.appspot.com/6855107

    -sml

    On Wednesday, November 21, 2012 10:27:43 AM UTC-8, sledb...@google.com
    wrote:
    So I've taken a stab at moving all the wire-touching code into another
    package (go.crypto/ssh/wire) and am currently refactoring the code where I
    can -- I'll let you know my progress once its stable enough, possibly send
    out a CL or 2.

    -sml
    On Tuesday, November 20, 2012 2:42:25 PM UTC-8, agl wrote:
    On Tue, Nov 20, 2012 at 5:35 PM, Dave Cheney wrote:
    Possibly these functions should move to their own package. I think there may
    be an issue similar to this in the issue tracker already.

    Agl, thoughts?
    Yes, I believe this is the second such request.

    go.crypto/ssh/marshal?

    It would probably be a bit of an exercise to do the actual separation
    (and I'm not volunteering) but I've no fundamental objections.


    Cheers

    AGL
    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 20, '12 at 10:42p
activeNov 27, '12 at 6:43p
posts5
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase