Questions about inferred state machines for OpenSSH

[Damien Miller]

On Tue, 26 Jan 2016, P. V. wrote:

> Dear all,
> 
> For my thesis, I've been working on automatic inference of state
> machines for SSH servers. I ran into a couple of particularities
> regarding OpenSSH's inferred state machine, and was hoping some of you
> might be interested. Maybe you can even shed some light on it.
> 
> Setup: I'm using LearnLib's (Java) version of the L* learning
> algorithm [1] to come up with sequences of textual representations of
> SSH messages (such as "DEBUG; DISCONNECT"). An altered version of
> Paramiko (Python) receives those queries and translates them to actual
> SSH traffic, which is sent to OpenSSH. Responses are fed to the
> learning algorithm, resulting in a state machine.

> The PDFs of inferred state machines, as well as the used messages, can
> be found online [2]. I've queried the the transport layer, user
> authentication layer and connection layer separately.
> 
> Now for my questions. Assuming my results are correct, it seems that:
> 1) OpenSSH is extremely liberal when it comes to exchanging kexinit
> messsages (openssh-localhost-L1.pdf). It allows entering a key
> exchange without receiving a proper kexinit message at all. Since this
> message is required to exchange parameters, does this imply that
> OpenSSH will guess those when no kexinit is received?

I'm not sure what you mean by "entering a key exchange without receiving
a proper kexinit message" because key exchange is initiated by a kexinit
message. Do you mean that method specific messages are accepted before
KEXINIT? (I can't see how this can happen from looking at the code).

> 2) OpenSSH does not allow rekeying until after correct user
> authentication. The RFCs specify otherwise. Is this a deliberate
> choice?

I don't think this is the case, it is true that ssh/sshd
fail to apply rekeying limits before completion of userauth but I
think they will respond to KEXINIT messages.

> 3) OpenSSH shows peculiar behavior in user re-authentication. Some
> re-authentication methods seem to be disallowed after an unsuccessful
> authentication attempt. You can see what I mean in
> openssh-localhost-L2.pdf. Is this intended behavior, a bug, or perhaps
> an error on my side?

Not sure what you mean here, but we don't support re-authentication
(as I understand the term). Do you mean subsequent authentication
requests after a "partial" authentication success, authentication
requests after a failed request or something different?

We certainly shouldn't allow requesting the userauth service after
userauth has completed.

> 4) Unlike other tested SSH servers, OpenSSH seems to close the entire
> connection (rather than close the channel) on a channel-close message
> in certain conditions. This results in the 'has_commands' and
> 'has_commands_pty' states in openssh-localhost-L3.pdf. I was wondering
> why. An error on my side, or intended behavior?

It would be helpful to see debug messages from ssh/sshd for this case
(well, all cases but this in particular).

-d