FAQ
Reviewers: golang-dev1,

Message:
Hello golang-dev@googlegroups.com (cc: agl@golang.org, dave@cheney.net,
jpsugar@google.com),

I'd like you to review this change to
https://code.google.com/p/go.crypto


Description:
go.crypto/ssh: reimplement SSH connection protocol modularly.

Adds the "mux" type, which implements the protocol on an
arbitrary packet transport. Client and server both use mux.

API changes for Channel:

- adds a CloseWrite() to the Channel type

- Read() no longer returns ChannelRequests.

- adds a ReceivedRequests() output channel. The channel must be
serviced or the connection mux will hang.

- Stderr() returns a ReadWriter.

- adds a SendRequest() method for sending channel requests

Please review this at https://codereview.appspot.com/14225043/

Affected files (+1389, -1308 lines):
    M ssh/channel.go
    M ssh/client.go
    M ssh/kex_test.go
    M ssh/messages.go
    A ssh/mux.go
    A ssh/mux_test.go
    M ssh/server.go
    M ssh/server_terminal.go
    M ssh/session.go
    M ssh/session_test.go
    M ssh/tcpip.go
    M ssh/test/session_test.go
    M ssh/test/test_unix_test.go


--

---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Hanwenn at Oct 5, 2013 at 8:07 pm
    hi guys,

    this is still a bit rough, but I think it warrants a first look. The API
    change which will cause the most pain is that Read() will no longer
    return ChannelRequest errors. I think the added type safety offsets the
    pain, and the requests weren't serialized with the read data anyway.

    Things to consider:

    * In the mux API, should we use functions, eg. Accept(), or channels,
    eg. ReceivedRequests()?

    * key change is not handled (I think it should be at transport level.)
    Did it work before? It was only server-side, not tested, and channel
    writes didn't seem to be synchronized with the key change messages.

    * should the mux be a public class? It could help people implement
    multiplexed transport between peers.


    https://codereview.appspot.com/14225043/

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Daniel Theophanes at Oct 6, 2013 at 3:09 am
    The key change on the server side was handled when the client initiated,
    though the server lacked the ability to initiate.

    -Daniel
    On Saturday, October 5, 2013 1:07:28 PM UTC-7, Han-Wen Nienhuys wrote:

    hi guys,

    this is still a bit rough, but I think it warrants a first look. The API
    change which will cause the most pain is that Read() will no longer
    return ChannelRequest errors. I think the added type safety offsets the
    pain, and the requests weren't serialized with the read data anyway.

    Things to consider:

    * In the mux API, should we use functions, eg. Accept(), or channels,
    eg. ReceivedRequests()?

    * key change is not handled (I think it should be at transport level.)
    Did it work before? It was only server-side, not tested, and channel
    writes didn't seem to be synchronized with the key change messages.

    * should the mux be a public class? It could help people implement
    multiplexed transport between peers.


    https://codereview.appspot.com/14225043/
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Han-Wen Nienhuys at Oct 6, 2013 at 7:56 am
    How can I test if this really works, ie. how do I make OpenSSH issue a rekeying?

    My concern specifically is this part of the server kex routine:

             if err = s.writePacket([]byte{msgNewKeys}); err != nil {
                     return
             }
             // *
             if err = s.transport.writer.setupKeys(serverKeys, result.K,
    result.H, s.sessionId, kex.Hash()); err != nil {
                     return
             }

    if another serverChan writes a packet at the point // * , it will use
    the old keys but the remote side will decrypt with the new keys.

    On Sun, Oct 6, 2013 at 5:09 AM, Daniel Theophanes wrote:
    The key change on the server side was handled when the client initiated,
    though the server lacked the ability to initiate.

    -Daniel
    On Saturday, October 5, 2013 1:07:28 PM UTC-7, Han-Wen Nienhuys wrote:

    hi guys,

    this is still a bit rough, but I think it warrants a first look. The API
    change which will cause the most pain is that Read() will no longer
    return ChannelRequest errors. I think the added type safety offsets the
    pain, and the requests weren't serialized with the read data anyway.

    Things to consider:

    * In the mux API, should we use functions, eg. Accept(), or channels,
    eg. ReceivedRequests()?

    * key change is not handled (I think it should be at transport level.)
    Did it work before? It was only server-side, not tested, and channel
    writes didn't seem to be synchronized with the key change messages.

    * should the mux be a public class? It could help people implement
    multiplexed transport between peers.


    https://codereview.appspot.com/14225043/


    --
    Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Daniel Theophanes at Oct 6, 2013 at 9:13 pm
    When implementing, I tested with putty which you can set the criteria
    when it re-keys, either with time or data transfers.
    On Sun, Oct 6, 2013 at 12:56 AM, Han-Wen Nienhuys wrote:
    How can I test if this really works, ie. how do I make OpenSSH issue a rekeying?

    My concern specifically is this part of the server kex routine:

    if err = s.writePacket([]byte{msgNewKeys}); err != nil {
    return
    }
    // *
    if err = s.transport.writer.setupKeys(serverKeys, result.K,
    result.H, s.sessionId, kex.Hash()); err != nil {
    return
    }

    if another serverChan writes a packet at the point // * , it will use
    the old keys but the remote side will decrypt with the new keys.

    On Sun, Oct 6, 2013 at 5:09 AM, Daniel Theophanes wrote:
    The key change on the server side was handled when the client initiated,
    though the server lacked the ability to initiate.

    -Daniel
    On Saturday, October 5, 2013 1:07:28 PM UTC-7, Han-Wen Nienhuys wrote:

    hi guys,

    this is still a bit rough, but I think it warrants a first look. The API
    change which will cause the most pain is that Read() will no longer
    return ChannelRequest errors. I think the added type safety offsets the
    pain, and the requests weren't serialized with the read data anyway.

    Things to consider:

    * In the mux API, should we use functions, eg. Accept(), or channels,
    eg. ReceivedRequests()?

    * key change is not handled (I think it should be at transport level.)
    Did it work before? It was only server-side, not tested, and channel
    writes didn't seem to be synchronized with the key change messages.

    * should the mux be a public class? It could help people implement
    multiplexed transport between peers.


    https://codereview.appspot.com/14225043/


    --
    Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Michael Hudson at Oct 6, 2013 at 9:26 pm

    On 2013/10/06 21:13:41, kardia wrote:
    When implementing, I tested with putty which you can set the criteria
    when it re-keys, either with time or data transfers.
    You can also type "~R" in an interactive session with openssh.


    https://codereview.appspot.com/14225043/

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedOct 5, '13 at 8:03p
activeOct 6, '13 at 9:26p
posts6
users4
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase