please decrypt your manuals

[Keisial]

Doru Georgescu wrote:
> The attacker does not have some private decryption key? Anyway, this is too involved for me now, but thank you anyway. 
>
> Doru 
>   

No. The server private key [for the connection] is only held on the
server memory. That's the reason sshd has a "long" startup time and is
unsuitable to spawn a sshd on each connection from inetd.
Moreover, the server ephemeral key (on ssh v1) is changed each
KeyRegenerationInterval econds, and on ssh v2 RekeyLimit establishes
after how much data transferred the session key (the key used connecting
with this user) is renegotiated.

It is designed in such way that even if the attacker dumps all the
network packets, and later it is able to compromise the machine, it
still cannot figure out the contents of the transmission (this doesn't
include logs of user actions as .bash_history, breaking in the machine
with a "later" time so short that it can read the daemon memory...).


> Precisely because ssh is the work of a community, it is largely meaningless for me to write a manual alone, without tight cooperation with that community. The manual should transmit information from developers to users. For this to happen, a language (symbols, terminology, structure, logical implication rules) should be developed. The very idea that I can do this alone, outside the developers' community, is absurd. Of course such a manual would be rejected, because it would not make any sense to the developers. 
>   
You can improve per sections, so you get immediate feedback on how you
are doing, can correct easier and spend less resources if doing bad.
Being smaller changes, it also eases review.

Summarising sparse explanations given in a mailing list from the
/cognoscenti/ is a good way of creating documentation. But yes, it
requires quite a bit of struggling to find the right information before
"the perfect manual" can be made.