Following up on my own thread.
I was able to get logging from sshd to stderr using 'sshd -e', but it appears as if internal-sftp does not send messages to stderr (or, at least, to the same file handle). With 'LogLevel VERBOSE', sshd emits expected messages about connection and accepting keys, then:
User child is on pid 1234
Starting session: subsystem'sftp' for user1 from 1.2.3.4 port 5678 id 0
It's not until closing the session that we get more:
Close session: user user1 from 1.2.3.4 port 5678 id 0
Received disconnect from 1.2.3.4 port 5678:12: disconnected by user
[...]
As expected, command-line flags in sshd_config for the internal-sftp command have no effect ('-e -l DEBUG', for example).
I haven't looked at the code to see whether there's an easy path here or not. Too bad, it seemed like a reasonable approach -- and could still be, if someone were to implement a reasonable "log-to-stderr" for internal sftp.
The only other approach that's seems at all reasonable to me is to add code and a config twiddle to sshd to send log messages directly to, say, an RFC5425 syslog-over-TLS server at a configurable address and port. That seems like a lot of code for not so much benefit.
--
jmk
> On Sep 29, 2021, at 20:44, Jim Knoble <jmknoble@xxxxxxxxx> wrote:
>
>
> If 'internal-sftp' means that the SFTP server is just a forked child of sshd, would the 'sshd -e' flag work to send log messages from internal-sftp to stderr?
>
> If so, it may be worth just sending all logging from sshd to stderr (sowie [daemontools]).
>
> Someone with time and ingenuity on their hands may even be able to send the stderr output on to syslog-ng and dispense with any need to filter it or send it to a file....
>
> If internal-sftp doesn't work that way for ${reasons}, it may be worth adding that functionality for this sort of use case.
>
> ____________________
> [daemontools]: https://cr.yp.to/daemontools.html
>
>
> --
> jmk
>
>>> On Sep 29, 2021, at 19:44, Peter Stuge <peter@xxxxxxxx> wrote:
>>>
>> Small clarification:
>>
>> Hildegard Meier wrote:
>>> ps auxww |grep sftp
>>> root 4192 0.0 0.1 72304 6512 ? Ss 11:01 0:00 /usr/sbin/sftpd -D -f /etc/sftpd/sftpd_config
>>> root 4590 0.2 0.1 74736 6632 ? Ss 11:05 0:00 sftpd: sftp_nagios [priv]
>>> sftp_na+ 4592 0.0 0.0 74736 3432 ? S 11:05 0:00 sftpd: sftp_nagios@notty
>>> sftp_na+ 4593 0.0 0.0 74736 3108 ? Ss 11:05 0:00 sftpd: sftp_nagios@internal-sftp
>>
>> 4192 /usr/sbin/sftpd is likely unrelated to OpenSSH.
>> I guess that this is a TLS FTP server.
>> Try ps fax to see process relationships.
>>
>> The "sftpd:" prefix for the sshd processes may be related to SELinux;
>> nothing in OpenSSH is called sftpd, except the "sftpd_t" SELinux context.
>>
>>
>> //Peter
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev@xxxxxxxxxxx
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
