Re: Howto log multiple sftpd instances with their chroot shared via NFS

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



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




[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux