f



ssh protocol question

hi

I'm personaly interested about ssh protocol, particularly the
begining of the session.

The session from a client to server starts this way (according to the RFCs):

-Client and server exchange identifiers: SSH version and OS version
-immediatly after this unencrypted exchange begins the Key Exchange, and all packets SHALL use the binary packet protocol (cf RFC 4523)

But this RFC 4523 says that the binary packet protocol is encrypted. 

The question(s): How come the client and server agree on an encryption for the binary packet protocol ? What algorithm and what key are they using ?

Sorry if this out of topic, but i don't know where to put this question.

--
cmic, retired but curious SysAdmin


0
banjo
11/2/2016 8:59:01 AM
comp.security.ssh 4228 articles. 0 followers. terra1024 (490) is leader. Post Follow

3 Replies
218 Views

Similar Articles

[PageSpeed] 13

<banjo.cmic@gmail.com> wrote:
> -immediatly after this unencrypted exchange begins the Key Exchange, and
> all packets SHALL use the binary packet protocol (cf RFC 4523)
> 
> But this RFC 4523 says that the binary packet protocol is encrypted. 

(RFC 4253, not 4523.)

The binary packet protocol _can_ be encrypted, but is not always. Note
the "When encryption is in effect" in this paragraph of RFC 4253
section 6.3, implying that there are times when encryption is *not* in
effect:

  An encryption algorithm and a key will be negotiated during the key
  exchange. When encryption is in effect, the packet length, padding
  length, payload, and padding fields of each packet MUST be encrypted
  with the given algorithm.

Before the first key exchange has finished its negotiation, encryption
is not in effect, which means that the listed fields of the packet are
simply sent in cleartext, and the MAC field is completely omitted (or,
if you prefer, it is zero bytes long :-). The first packet transmitted
by either end with encryption and a MAC is the one following that
end's first SSH_MSG_NEWKEYS.

(I agree that this detail is surprisingly hard to find an explicit
mention of in the RFC, though.)

> Sorry if this out of topic, but i don't know where to put this question.

It's completely on-topic here as far as I'm concerned! Traffic in this
newsgroup _mostly_ tends to be about the usage of particular SSH
implementations rather than the underlying protocol, but protocol
discussions do happen as well from time to time.
-- 
import hashlib; print (lambda p,q,g,y,r,s,m: m if (lambda w:(pow(g,int(hashlib.
 sha1(m).hexdigest(),16)*w%q,p)*pow(y,r*w%q,p)%p)%q)(pow(s,q-2,q))==r else "!"
 )(0xb80b5dacabab6145, 0xf70027d345023, 0x7643bc4018957897, 0x11c2e5d9951130c9,
 0xa54d9cbe4e8ab, 0x746c50eaa1910, "Simon Tatham <anakin@pobox.com>")
0
Simon
11/2/2016 1:03:57 PM
Hello
On Wednesday, November 2, 2016 at 2:04:00 PM UTC+1, Simon Tatham wrote:
> <banjo.cmic@gmail.com> wrote:
....

> (RFC 4253, not 4523.)

OOps . Sorry for the typo.

> 
....

> Before the first key exchange has finished its negotiation, encryption
> is not in effect, which means that the listed fields of the packet are
> simply sent in cleartext, and the MAC field is completely omitted (or,
                                    ^^^
You mean the Message Authentication Code I presume. (Not MAC address)

> if you prefer, it is zero bytes long :-). The first packet transmitted
> by either end with encryption and a MAC is the one following that
> end's first SSH_MSG_NEWKEYS.


I'm gonna launch a Wireshark session to see what really happens on my lan. (BTW I use your "PuTTY snapshot 2016-10-10" whith new ECDH an ciphers)

Thanks ever so much for your explanations.
--
cmic
0
banjo
11/6/2016 9:19:54 PM
<banjo.cmic@gmail.com> wrote:
> You mean the Message Authentication Code I presume. (Not MAC address)

Yes - MAC addresses are completely irrelevant to the SSH protocol
(which doesn't even _have_ to be sent over TCP/IP, let alone over a
link layer with MAC addresses), so in the context of SSH, 'MAC' will
always denote the Message Authentication Code used for integrity
protection in the binary packet protocol.

> I'm gonna launch a Wireshark session to see what really happens on my
> lan.

If you're using PuTTY, you can also get it to log all the SSH packets
in hex, which will allow you to see what's going on inside even the
encrypted part of the session.

Cheers,
Simon
-- 
import hashlib; print (lambda p,q,g,y,r,s,m: m if (lambda w:(pow(g,int(hashlib.
 sha1(m).hexdigest(),16)*w%q,p)*pow(y,r*w%q,p)%p)%q)(pow(s,q-2,q))==r else "!"
 )(0xb80b5dacabab6145, 0xf70027d345023, 0x7643bc4018957897, 0x11c2e5d9951130c9,
 0xa54d9cbe4e8ab, 0x746c50eaa1910, "Simon Tatham <anakin@pobox.com>")
0
Simon
11/6/2016 10:20:29 PM
Reply: