Mailing List Archive: SSH as discard server?

SSH as discard server?

Aug 6, 2021, 8:09 AM

Post #1 of 3 (312 views)

Before I go about reinventing the wheel I thought I would ask here.

I'm doing some development in SSH and it would be helpful if I could
isolate certain aspects of what I am working on. What I would like to do
is have an SSH aware discard server that accepts an inbound connection
from an SSH client and then dumps every incoming packet into a black
hole. I don't want to process, decrypt, or otherwise do anything with
those packets post authentication. Switching to a none cipher won't work
as it would require both ends to renegotiate to none. Likewise, just
redirecting the output to /dev/null means I'm still spending cycles
decrypting and verifying the HMAC.

So does anyone know of any existing implementations that can do this? If
not, does anyone have any suggestions as to where to start? I'm thinking
that adding a new CFLAG so I can do a discard in in cipher_crypt would
be reasonable but I wanted to get any thoughts people might have.

e.g. if ((cc->cipher->flags & CFLAG_DISCARD) != 0) {
return 0;
}

Thanks,

Chris
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: SSH as discard server? [ In reply to ]

b.candler at pobox

Aug 6, 2021, 8:27 AM

Post #2 of 3 (312 views)

Permalink

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

Re: SSH as discard server? [ In reply to ]

rapier at psc

Aug 6, 2021, 8:47 AM

Post #3 of 3 (312 views)

Permalink

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