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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
