Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- Harold Johanssen
April 12, 2014, 3:57 pm
rate this thread
understanding of the SSH foundations. I have come across something I am
finding a bit intriguing; hopefully somebody well versed into the
intricacies of the RFCs might help me here.
IN RFC 4254, section 5.1, the SSH_MSG_CHANNEL_OPEN is described.
One of the pieces of information conveyed in this message is the maximum
size of packets to be exchanged between client and server. The RFC then
says that this can be used to select smaller maximum packet sizes for
If I understand the RFC correctly, that is true for the client,
but not by the server. The client sends an SSH_MSG_CHANNEL_OPEN message
proposing a maximum packet size, and the server responds with
SSH_MSG_CHANNEL_OPEN_CONFIRMATION where it specifies the maximum packet
size that it will accept.
Now at that point the client obviously must know what type of
session it wishes to establish - therefore it can select the maximum
packet size accordingly. However, the server will still not have the
session type information - which will be conveyed by the client when
sending an SSH_MSG_CHANNEL_REQUEST message later on.
Is this a correct reading of the RFC? If so, is the implication
that the server just can't make a decision concerning the maximum packet
size that it will accept on the basis of the type of session that the
client is trying to establish, or is there a way around this?
Re: Question about the SSHv2.0 protocol specification
It's not so much 'proposing': each side specifies the maximum packet
size _it_ is willing to accept. The max packet size in the client's
CHANNEL_OPEN is not a _proposal_; it's a hard limit that the server
must honour when sending channel data to the client. And conversely,
the max packet size in CHANNEL_OPEN_CONFIRMATION is a hard limit that
the client must honour when sending channel data to the server.
(Incidentally, client and server aren't always that way round: some
channel types, e.g. 'forwarded-tcpip' and agent forwarding, are opened
by the server.)
Yes and no. For some channel types (e.g. 'direct-tcpip') the channel
type is given as part of the CHANNEL_OPEN. It's only the 'session'
channel type where important auxiliary type information is deferred
until the CHANNEL_REQUEST that says whether you're launching a shell
or a subsystem or what.
Bear in mind that interactive sessions generally transmit individual
keystrokes (plus occasional pastes) from client to server, so the
packet size limit in the client->server direction will not generally
be attained! So the max packet size specified by the client for the
server->client side is the interesting one, if either one is.
Personally I don't really see what the big deal is with max packet
size anyway. If I have a lot of data to send to the other end and it's
specified a too-small max packet, then I have to split it up into
multiple packets which I send in rapid succession, but what difference
does that make to anything? A few bytes of overhead more or less is
about all. _Window_ size is actually important, because that forces me
to buffer more stuff at my end and push back on the sender if it's not
going through fast enough, but max packet size is just a matter of
whether or not I put an arbitrary packet boundary in the middle of my
data, but I send basically the same data either way, so who cares?
Simon Tatham "Thieves respect property; they only wish the property to
- » Making an ssh alias vary inside & outside the LAN?
- — Next thread in » Secure Shell Forum
- » ssh on command line: force using a group size (prime size) of 1024 (and no...
- — Newest thread in » Secure Shell Forum