Understood. That's why I was looking at doing in cipher_crypt. All the
other mechanism should JustWork(tm). Maybe.
That said, that's sort of what I do in the none cipher switch in hpnssh.
Instead of running through a decrypt process it just does a memcpy from
src to dst and returns.
Thanks
Chris
On 8/6/21 11:27 AM, Brian Candler wrote:
After authentication, the ssh client is almost certainly going to
request a channel. If you don't acknowledge that, it will hang. It can
then request further channels at any point during the connection.
Handling this requires decrypting the traffic. Any "sink" server that
doesn't bother to decrypt packets will need to be written in a way which
is very specific to the way the client uses SSH.
From the intro to rfc4254:
This document describes the SSH Connection Protocol. It provides
interactive login sessions, remote execution of commands, forwarded
TCP/IP connections, and forwarded X11 connections. **All of these channels are multiplexed into a single encrypted tunnel**.
(my emphasis)
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
