openssh unix dev - Aug 2017 - Filter files received on scp server

Hey folks,


For reasons, I am trying to restrict what files the scp server will accept.


I've been running "/usr/sbin/sshd  -D -ddd -e" to try to debug
what exactly is going on, program flow, etc, but I am not seeing the information
I want.  I have tracked the flow to sshd calling 'scp -t .', but I
cannot seem to proceed from that point.


I cannot seem to get any log or debug or any information out of the spawned scp
process.  I got one debug message from sshd (just before it spawns the scp
chile) echoed to my -client- machine, no idea why that happened, but, I would
love to be able to sprinkle some prints and things throughout scp so I can see
what is happening.


Further adding to my confusion, the debug output from sshd is emitting many
messages from channel and session methods, during the file transfer, so I am not
sure what is going on.  I would love to see an architecture document but I doubt
that exists.  LOL


I also found an issue
"https://bugzilla.mindrot.org/show_bug.cgi?id=2705" which added
logging to ssh. I was trying to add it myself, by calling log_init, then using
the debug method, scp does not produce any output.


So, either I did it wrong, or scp is not used on the server at all, to transfer
files.


So, I am hoping to receive a little guidance on where I should be focusing my
attention and changes.


Many thanks!

Jon

Quoting Jon Earle <earlej at hotmail.com>:
> Hey folks,
> 
> 
> For reasons, I am trying to restrict what files the scp server will accept.
Are you trying to filter based on filenames or as a completion task upon
successful receipt of the accepted files through ClamAV or similar scanning
tool. (Let's call the first example "Type A" and the second
"Type B".)  Or
alternatively, you could just use "file magic" detection of *ANY*
system
executable, for a much lighter weight "threat scanning". Let's
call that Type
C (or B-Light).

With Type B (and probably C), I'm assuming you'd quarantine the file(s)
in
transit until the scanning is complete, with a successful result
"releasing"
the file to its proper location, while a "failed" file would be
deleted or
quarantined with log entries to describe the situation.  This sounds like a
much "heavier" change to make to sshd than Type A, even if it is the
more
effective strategy.

You're patching the code on the server and/or running the server's sshd
with
the appropriate debug/logging settings, correct?

=M=

Hey,

So, I would be looking at type A. Forgive me if my understanding of how OpenSSH
operates is not reflective of reality. I am assuming that, the file transfer is
happening somewhat logically, with a name being known, content written, blah
blah.
>From reading scp.c, it appears that, the client end at least knows the file
name so I must assume the server end must be given it.
I am hoping to filter on that file name so I can reject certain files (ideally,
configurable file patterns).  Suppose I wish for all files named
"kitten.txt" to be rejected, I would simply compare the incoming file
name to that and, if a match, end the transfer and session.

Not using any third party apps, nor will I propose any - I wish to make sshd/scp
dance this dance, if I can.

Note that, if it's actually impossible to do this, that's an acceptable
outcome. Not preferred - I hate giving up - but, an uncomfortable answer is
still an answer.

Cheers!
Jon
________________________________
From: openssh-unix-dev <openssh-unix-dev-bounces+earlej=hotmail.com at
mindrot.org> on behalf of Morham Anthelleron <opensshdev at
r.paypc.com>
Sent: Thursday, August 3, 2017 7:33:30 PM
To: openssh-unix-dev at mindrot.org
Subject: Re: Filter files received on scp server

Quoting Jon Earle <earlej at hotmail.com>:
> Hey folks,
>
>
> For reasons, I am trying to restrict what files the scp server will accept.
Are you trying to filter based on filenames or as a completion task upon
successful receipt of the accepted files through ClamAV or similar scanning
tool. (Let's call the first example "Type A" and the second
"Type B".)  Or
alternatively, you could just use "file magic" detection of *ANY*
system
executable, for a much lighter weight "threat scanning". Let's
call that Type
C (or B-Light).

With Type B (and probably C), I'm assuming you'd quarantine the file(s)
in
transit until the scanning is complete, with a successful result
"releasing"
the file to its proper location, while a "failed" file would be
deleted or
quarantined with log entries to describe the situation.  This sounds like a
much "heavier" change to make to sshd than Type A, even if it is the
more
effective strategy.

You're patching the code on the server and/or running the server's sshd
with
the appropriate debug/logging settings, correct?

=M
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev