Mailing List Archive: sftp and utmp

sftp and utmp

Mar 30, 2023, 1:43 PM

Post #1 of 20 (1118 views)

Hi,

We need to limit concurrent sftp logins to one per user (because of bad
client behaviour). Is there any way to achieve this I have overlooked?

It seems it could be possible with pam_limits, if sftp sessions were
recorded in utmp (a guess from what I found googling around). If I
configure /etc/security/limits.conf with

testuser hard maxlogins 1

and connect with ssh, and try a second connection with sftp, the sftp
fails because there is already one session open. But if I connect with
sftp and try a second sftp connection, it is allowed.

Is there some way to have sftp connections recorded in utmp? I haven't
found any reference to this. There are some posts from 10+ years ago
where others were trying the same thing but there's no reply about how
to do it. Would it be possible to add this option?

We're using ChrootDirectory and ForceCommand internal-sftp, if it makes
a difference (I've tried without and had the same results).

Tried this on Debian bookworm's openssh-server (9.2). The changelog
from 9.3 does not mention anything related to this.

Thank you,

Fran?ois

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

Re: sftp and utmp [ In reply to ]

hvjunk at gmail

Mar 30, 2023, 2:12 PM

Post #2 of 20 (1118 views)

I've been battling similar issues, and the only methods I've found (with sftp) was to use
software like pureftd or crushftp (using crushftp lately as production) that does handle these
issues "out of the box"
Other than that, I'd expect you'll need to write your own PAM modules to track the accounting part to
enforce the limits yourself, as you'll need to account for the sftp different from the terminal sessions

> On 30 Mar 2023, at 22:43, François Ouellet <franco@sol.mpact.tv> wrote:
>
> Hi,
>
> We need to limit concurrent sftp logins to one per user (because of bad
> client behaviour). Is there any way to achieve this I have overlooked?
>
> It seems it could be possible with pam_limits, if sftp sessions were
> recorded in utmp (a guess from what I found googling around). If I
> configure /etc/security/limits.conf with
>
> testuser hard maxlogins 1
>
> and connect with ssh, and try a second connection with sftp, the sftp
> fails because there is already one session open. But if I connect with
> sftp and try a second sftp connection, it is allowed.
>
> Is there some way to have sftp connections recorded in utmp? I haven't
> found any reference to this. There are some posts from 10+ years ago
> where others were trying the same thing but there's no reply about how
> to do it. Would it be possible to add this option?
>
> We're using ChrootDirectory and ForceCommand internal-sftp, if it makes
> a difference (I've tried without and had the same results).
>
> Tried this on Debian bookworm's openssh-server (9.2). The changelog
> from 9.3 does not mention anything related to this.
>
> Thank you,
>
> François
>
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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

Re: sftp and utmp [ In reply to ]

hvjunk at gmail

Mar 30, 2023, 2:14 PM

Post #3 of 20 (1118 views)

> On 30 Mar 2023, at 23:12, hvjunk <hvjunk@gmail.com> wrote:
>
> I've been battling similar issues, and the only methods I've found (with sftp) was to use
> software like pureftd

oops, I meant ProFTPD (Keep swapping those two as I had need for each in different cases!)

> or crushftp (using crushftp lately as production) that does handle these
> issues "out of the box"
> Other than that, I'd expect you'll need to write your own PAM modules to track the accounting part to
> enforce the limits yourself, as you'll need to account for the sftp different from the terminal sessions
>
>
>
>> On 30 Mar 2023, at 22:43, François Ouellet <franco@sol.mpact.tv> wrote:
>>
>> Hi,
>>
>> We need to limit concurrent sftp logins to one per user (because of bad
>> client behaviour). Is there any way to achieve this I have overlooked?
>>
>> It seems it could be possible with pam_limits, if sftp sessions were
>> recorded in utmp (a guess from what I found googling around). If I
>> configure /etc/security/limits.conf with
>>
>> testuser hard maxlogins 1
>>
>> and connect with ssh, and try a second connection with sftp, the sftp
>> fails because there is already one session open. But if I connect with
>> sftp and try a second sftp connection, it is allowed.
>>
>> Is there some way to have sftp connections recorded in utmp? I haven't
>> found any reference to this. There are some posts from 10+ years ago
>> where others were trying the same thing but there's no reply about how
>> to do it. Would it be possible to add this option?
>>
>> We're using ChrootDirectory and ForceCommand internal-sftp, if it makes
>> a difference (I've tried without and had the same results).
>>
>> Tried this on Debian bookworm's openssh-server (9.2). The changelog
>> from 9.3 does not mention anything related to this.
>>
>> Thank you,
>>
>> François
>>
>>
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev@mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

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

Re: sftp and utmp [ In reply to ]

jmg at funkthat

Mar 31, 2023, 2:47 PM

Post #4 of 20 (1118 views)

hvjunk wrote this message on Thu, Mar 30, 2023 at 23:12 +0200:
> I've been battling similar issues, and the only methods I've found (with sftp) was to use
> software like pureftd or crushftp (using crushftp lately as production) that does handle these
> issues "out of the box"
> Other than that, I'd expect you'll need to write your own PAM modules to track the accounting part to
> enforce the limits yourself, as you'll need to account for the sftp different from the terminal sessions

You could use an sftp-server wrapper script that creates a lock file/dir
or another way to detect if a connection is already present, and then
force the use of that script via the sshd_config Subsystem directive.

> > On 30 Mar 2023, at 22:43, Fran?ois Ouellet <franco@sol.mpact.tv> wrote:
> >
> > Hi,
> >
> > We need to limit concurrent sftp logins to one per user (because of bad
> > client behaviour). Is there any way to achieve this I have overlooked?
> >
> > It seems it could be possible with pam_limits, if sftp sessions were
> > recorded in utmp (a guess from what I found googling around). If I
> > configure /etc/security/limits.conf with
> >
> > testuser hard maxlogins 1
> >
> > and connect with ssh, and try a second connection with sftp, the sftp
> > fails because there is already one session open. But if I connect with
> > sftp and try a second sftp connection, it is allowed.
> >
> > Is there some way to have sftp connections recorded in utmp? I haven't
> > found any reference to this. There are some posts from 10+ years ago
> > where others were trying the same thing but there's no reply about how
> > to do it. Would it be possible to add this option?
> >
> > We're using ChrootDirectory and ForceCommand internal-sftp, if it makes
> > a difference (I've tried without and had the same results).
> >
> > Tried this on Debian bookworm's openssh-server (9.2). The changelog
> > from 9.3 does not mention anything related to this.

--
John-Mark Gurney Voice: +1 415 225 5579

"All that I will do, has been done, All that I have, has not."
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: sftp and utmp [ In reply to ]

philipp at marek

Mar 31, 2023, 11:06 PM

Post #5 of 20 (1118 views)

Set a max-process ulimit in /etc/security/limits.conf (using a group specification).

For internal sftp 1, for external 2, I guess.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: sftp and utmp [ In reply to ]

Apr 2, 2023, 9:05 PM

Post #6 of 20 (1117 views)

On Thu, 30 Mar 2023, Fran?ois Ouellet wrote:

> Hi,
>
> We need to limit concurrent sftp logins to one per user (because of bad
> client behaviour). Is there any way to achieve this I have overlooked?
>
> It seems it could be possible with pam_limits, if sftp sessions were
> recorded in utmp (a guess from what I found googling around). If I
> configure /etc/security/limits.conf with
>
> testuser hard maxlogins 1
>
> and connect with ssh, and try a second connection with sftp, the sftp
> fails because there is already one session open. But if I connect with
> sftp and try a second sftp connection, it is allowed.
>
> Is there some way to have sftp connections recorded in utmp? I haven't
> found any reference to this. There are some posts from 10+ years ago
> where others were trying the same thing but there's no reply about how
> to do it. Would it be possible to add this option?

We've been asked about this a number of times before - the problem is
that utmp is really set up to record interactive logins that have a
TTY/PTY assigned. There is AFAIK no real standard for recording
"service logins" (e.g. sftp or SSH command execution w/o TTY) in utmp
and many OS utmp implementation lack fields by which this could be
communicated.

IIRC we toyed with recording something fake like "sftp" in ut_line
but that caused problems as none of the other tools were set up to
accept it.

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

Re: sftp and utmp [ In reply to ]

Apr 3, 2023, 6:38 AM

Post #7 of 20 (1117 views)

Le Friday, 31 March 2023, 17:47:14 EDT John-Mark Gurney a ?crit :
> hvjunk wrote this message on Thu, Mar 30, 2023 at 23:12 +0200:
> > I've been battling similar issues, and the only methods I've found (with sftp) was to use
> > software like pureftd or crushftp (using crushftp lately as production) that does handle these
> > issues "out of the box"
> > Other than that, I'd expect you'll need to write your own PAM modules to track the accounting part to
> > enforce the limits yourself, as you'll need to account for the sftp different from the terminal sessions
>
> You could use an sftp-server wrapper script that creates a lock file/dir
> or another way to detect if a connection is already present, and then
> force the use of that script via the sshd_config Subsystem directive.

I'm using the internal-sftp server, because it's a chrooted setup.
Not sure this can easily be done with this setup

Thanks,

Fran?ois

>
> > > On 30 Mar 2023, at 22:43, Fran?ois Ouellet <franco@sol.mpact.tv> wrote:
> > >
> > > Hi,
> > >
> > > We need to limit concurrent sftp logins to one per user (because of bad
> > > client behaviour). Is there any way to achieve this I have overlooked?
> > >
> > > It seems it could be possible with pam_limits, if sftp sessions were
> > > recorded in utmp (a guess from what I found googling around). If I
> > > configure /etc/security/limits.conf with
> > >
> > > testuser hard maxlogins 1
> > >
> > > and connect with ssh, and try a second connection with sftp, the sftp
> > > fails because there is already one session open. But if I connect with
> > > sftp and try a second sftp connection, it is allowed.
> > >
> > > Is there some way to have sftp connections recorded in utmp? I haven't
> > > found any reference to this. There are some posts from 10+ years ago
> > > where others were trying the same thing but there's no reply about how
> > > to do it. Would it be possible to add this option?
> > >
> > > We're using ChrootDirectory and ForceCommand internal-sftp, if it makes
> > > a difference (I've tried without and had the same results).
> > >
> > > Tried this on Debian bookworm's openssh-server (9.2). The changelog
> > > from 9.3 does not mention anything related to this.

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

Re: sftp and utmp [ In reply to ]

Apr 3, 2023, 6:44 AM

Post #8 of 20 (1117 views)

Le Saturday, 1 April 2023, 02:06:04 EDT Philipp Marek a ?crit :
> Set a max-process ulimit in /etc/security/limits.conf (using a group specification).
>
> For internal sftp 1, for external 2, I guess.

I'v seen this suggested before and I have tried it then. It doesn't
work with this particular config. I don't know why yet. It works when
I don't use the internal-sftp and ChrootDirectory.

Thanks,

Fran?ois

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

Re: sftp and utmp [ In reply to ]

hvjunk at gmail

Apr 3, 2023, 7:01 AM

Post #9 of 20 (1117 views)

> On 03 Apr 2023, at 15:44, François Ouellet <franco@sol.mpact.tv> wrote:
>
> Le Saturday, 1 April 2023, 02:06:04 EDT Philipp Marek a écrit :
>> Set a max-process ulimit in /etc/security/limits.conf (using a group specification).
>>
>> For internal sftp 1, for external 2, I guess.
>
>
> I'v seen this suggested before and I have tried it then. It doesn't
> work with this particular config. I don't know why yet. It works when
> I don't use the internal-sftp and ChrootDirectory.

I *suspect* it's 'cause the process limits are (firstly) applied to the ssd, which then forks and load the sftp, thus it might not be seen as an sftp, but only a sshd process.

Having worked with opensshd, and other solutions, opensshd isn't really meant to handle these bad actors...once the actor have been authenticated, and the connections are there, OPenSSH basically steps out of the picture, so this type of limiting I'm not expecting to be an openssh service nor function.

When you have these type of issues, rather (and I'm doing it for these and other security related reasons) extract the sftp function for those file transfer type services, and put it on a dedicated program that will deal with these type of bad actors in more organized/designed manner.

My goto (for file transfers) is the Commercially available CrushFTP (WELL priced for the number of users) and ProFTPd as an opensource option again designed for these type of handling of bad actors

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

Re: sftp and utmp [ In reply to ]

hvjunk at gmail

Apr 3, 2023, 7:01 AM

Post #10 of 20 (1117 views)

> On 03 Apr 2023, at 15:44, François Ouellet <franco@sol.mpact.tv> wrote:
>
> Le Saturday, 1 April 2023, 02:06:04 EDT Philipp Marek a écrit :
>> Set a max-process ulimit in /etc/security/limits.conf (using a group specification).
>>
>> For internal sftp 1, for external 2, I guess.
>
>
> I'v seen this suggested before and I have tried it then. It doesn't
> work with this particular config. I don't know why yet. It works when
> I don't use the internal-sftp and ChrootDirectory.

I *suspect* it's 'cause the process limits are (firstly) applied to the ssd, which then forks and load the sftp, thus it might not be seen as an sftp, but only a sshd process.

Having worked with opensshd, and other solutions, opensshd isn't really meant to handle these bad actors...once the actor have been authenticated, and the connections are there, OPenSSH basically steps out of the picture, so this type of limiting I'm not expecting to be an openssh service nor function.

When you have these type of issues, rather (and I'm doing it for these and other security related reasons) extract the sftp function for those file transfer type services, and put it on a dedicated program that will deal with these type of bad actors in more organized/designed manner.

My goto (for file transfers) is the Commercially available CrushFTP (WELL priced for the number of users) and ProFTPd as an opensource option again designed for these type of handling of bad actors

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

Re: sftp and utmp [ In reply to ]

hvjunk at gmail

Apr 3, 2023, 7:08 AM

Post #11 of 20 (1117 views)

> On 03 Apr 2023, at 15:38, François Ouellet <franco@sol.mpact.tv> wrote:
>
> I'm using the internal-sftp server, because it's a chrooted setup.
> Not sure this can easily be done with this setup

Yes, I know it's not OpenSSH, I'm just a happy user, but seriously for this use case, consider CrushFTP, or ProFTPd for the opernsource with the sftp module

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

Re: sftp and utmp [ In reply to ]

Apr 3, 2023, 7:12 AM

Post #12 of 20 (1117 views)

Le Monday, 3 April 2023, 00:05:25 EDT Damien Miller a ?crit :
> On Thu, 30 Mar 2023, Fran?ois Ouellet wrote:
>
> > Hi,
> >
> > We need to limit concurrent sftp logins to one per user (because of bad
> > client behaviour). Is there any way to achieve this I have overlooked?
> >
> > It seems it could be possible with pam_limits, if sftp sessions were
> > recorded in utmp (a guess from what I found googling around). If I
> > configure /etc/security/limits.conf with
> >
> > testuser hard maxlogins 1
> >
> > and connect with ssh, and try a second connection with sftp, the sftp
> > fails because there is already one session open. But if I connect with
> > sftp and try a second sftp connection, it is allowed.
> >
> > Is there some way to have sftp connections recorded in utmp? I haven't
> > found any reference to this. There are some posts from 10+ years ago
> > where others were trying the same thing but there's no reply about how
> > to do it. Would it be possible to add this option?
>
> We've been asked about this a number of times before - the problem is
> that utmp is really set up to record interactive logins that have a
> TTY/PTY assigned. There is AFAIK no real standard for recording
> "service logins" (e.g. sftp or SSH command execution w/o TTY) in utmp
> and many OS utmp implementation lack fields by which this could be
> communicated.
>
> IIRC we toyed with recording something fake like "sftp" in ut_line
> but that caused problems as none of the other tools were set up to
> accept it.

Is there an archive of the discussion of the problems it brings to the
other tools? I'd like to understand the issues.

What other tools are impacted? If I don't need them, would it be
possible to think about adding an option to enter fake utmp entries for
interal-sftp sessions (or any other subsystem, I'm only seeing my own
little problem here)?

Could I find some code from those tests from some time ago and apply
it locally? Was there anything publicly available? A quick glance
at the code was not enough for me to see anything obvious that could
be done.

I still have some (small) hope of achieving what I need with pam_limits
and nproc if the fake utmp entry is not possible...

Thanks,

Fran?ois

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

Re: sftp and utmp [ In reply to ]

Apr 3, 2023, 7:29 AM

Post #13 of 20 (1117 views)

Le Monday, 3 April 2023, 10:08:08 EDT hvjunk a ?crit :
>
> > On 03 Apr 2023, at 15:38, Fran?ois Ouellet <franco@sol.mpact.tv> wrote:
> >
> > I'm using the internal-sftp server, because it's a chrooted setup.
> > Not sure this can easily be done with this setup
>
> Yes, I know it's not OpenSSH, I'm just a happy user, but seriously for this use case, consider CrushFTP, or ProFTPd for the opernsource with the sftp module

I will have a look.

Thank you very much,

Fran?ois

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

Re: sftp and utmp [ In reply to ]

Jochen.Bern at binect

Apr 3, 2023, 10:29 AM

Post #14 of 20 (1117 views)

On 30.03.23 22:43, François Ouellet wrote:
> We need to limit concurrent sftp logins to one per user (because of bad
> client behaviour). Is there any way to achieve this I have overlooked?

What authentication method(s) do your users use?

On our Internet-facing SFTP server, by default (few exceptions), we
accept only pubkey auth and require users to (un)install pubkeys through
us. In order to keep that latter out of users' hands, we use
AuthorizedKeysCommand (rather than AuthorizedKeysFile) pointing to a
little shell script (that has to look up and copy the acceptable pubkeys
for the user to stdout). Inserting a "ps" to look for ongoing logins of
the same user, and having the script exit without any output if found,
should be easy ...

> PasswordAuthentication no
> ChallengeResponseAuthentication no
> GSSAPIAuthentication no
> Subsystem sftp internal-sftp
[...]
> Match group JUST-SFTP_USERS_GROUP
> ChrootDirectory %h
[...]
> ForceCommand internal-sftp -l INFO -u 0077
[...]
> AuthorizedKeysCommand AKC_SCRIPT
> AuthorizedKeysCommandUser AKC_USER

> $ cat AKC_SCRIPT
> #!/bin/sh
[...]
> MANDANT="$1"
> if [ "`echo $MANDANT | tr 'A-Za-z0-9-' _ | sed -e 's/^_*$/_/'`" != "_" ]; then
> # Unsupported characters in username. Refuse to work.
> $LOG.warning "Invalid username: $MANDANT"
> exit 0
> fi
[...]
> if [ -r "$MAIN_FILE" ]; then
> MAIN=`grep -c '^ *#'"$MANDANT"'# *ssh-' "$MAIN_FILE"`
> grep '^ *#'"$MANDANT"'# *ssh-' "$MAIN_FILE" | sed -e 's/^ *#'"$MANDANT"'# *//'
> fi
[...]
> exit 0
Kind regards,
--
Jochen Bern
Systemingenieur

Binect GmbH

Re: sftp and utmp [ In reply to ]

jmg at funkthat

Apr 3, 2023, 1:25 PM

Post #15 of 20 (1117 views)

Franois Ouellet wrote this message on Mon, Apr 03, 2023 at 09:38 -0400:
> Le Friday, 31 March 2023, 17:47:14 EDT John-Mark Gurney a ?crit :
> > hvjunk wrote this message on Thu, Mar 30, 2023 at 23:12 +0200:
> > > I've been battling similar issues, and the only methods I've found (with sftp) was to use
> > > software like pureftd or crushftp (using crushftp lately as production) that does handle these
> > > issues "out of the box"
> > > Other than that, I'd expect you'll need to write your own PAM modules to track the accounting part to
> > > enforce the limits yourself, as you'll need to account for the sftp different from the terminal sessions
> >
> > You could use an sftp-server wrapper script that creates a lock file/dir
> > or another way to detect if a connection is already present, and then
> > force the use of that script via the sshd_config Subsystem directive.
>
> I'm using the internal-sftp server, because it's a chrooted setup.
> Not sure this can easily be done with this setup

You could put the sftp-server program in each chroot, less than ideal,
or or by writing an suid root (always be careful w/ these) helper program
that does the chroot as needed, though it looks like the former is still
needed for the suid solution.

> > > > On 30 Mar 2023, at 22:43, Fran?ois Ouellet <franco@sol.mpact.tv> wrote:
> > > >
> > > > Hi,
> > > >
> > > > We need to limit concurrent sftp logins to one per user (because of bad
> > > > client behaviour). Is there any way to achieve this I have overlooked?
> > > >
> > > > It seems it could be possible with pam_limits, if sftp sessions were
> > > > recorded in utmp (a guess from what I found googling around). If I
> > > > configure /etc/security/limits.conf with
> > > >
> > > > testuser hard maxlogins 1
> > > >
> > > > and connect with ssh, and try a second connection with sftp, the sftp
> > > > fails because there is already one session open. But if I connect with
> > > > sftp and try a second sftp connection, it is allowed.
> > > >
> > > > Is there some way to have sftp connections recorded in utmp? I haven't
> > > > found any reference to this. There are some posts from 10+ years ago
> > > > where others were trying the same thing but there's no reply about how
> > > > to do it. Would it be possible to add this option?
> > > >
> > > > We're using ChrootDirectory and ForceCommand internal-sftp, if it makes
> > > > a difference (I've tried without and had the same results).
> > > >
> > > > Tried this on Debian bookworm's openssh-server (9.2). The changelog
> > > > from 9.3 does not mention anything related to this.

--
John-Mark Gurney Voice: +1 415 225 5579

"All that I will do, has been done, All that I have, has not."
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: sftp and utmp [ In reply to ]

Apr 3, 2023, 2:30 PM

Post #16 of 20 (1117 views)

On Mon, 3 Apr 2023, Fran?ois Ouellet wrote:

> > IIRC we toyed with recording something fake like "sftp" in ut_line
> > but that caused problems as none of the other tools were set up to
> > accept it.
>
> Is there an archive of the discussion of the problems it brings to the
> other tools? I'd like to understand the issues.

Discussion was probably on this list, though some of it might have
been by direct email.

> What other tools are impacted? If I don't need them, would it be
> possible to think about adding an option to enter fake utmp entries for
> interal-sftp sessions (or any other subsystem, I'm only seeing my own
> little problem here)?

Potentially anything that uses utmp is impacted. The difficulty of
figuring out what software is in this set is part of the problem.

> Could I find some code from those tests from some time ago and apply
> it locally? Was there anything publicly available? A quick glance
> at the code was not enough for me to see anything obvious that could
> be done.

No, I don't think anything was recorded.

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

Re: sftp and utmp [ In reply to ]

nkadel at gmail

Apr 4, 2023, 2:52 AM

Post #17 of 20 (1101 views)

On Mon, Apr 3, 2023 at 12:16?AM Damien Miller <djm@mindrot.org> wrote:
>
> On Thu, 30 Mar 2023, François Ouellet wrote:
>
> > Hi,
> >
> > We need to limit concurrent sftp logins to one per user (because of bad
> > client behaviour). Is there any way to achieve this I have overlooked?
> >
> > It seems it could be possible with pam_limits, if sftp sessions were
> > recorded in utmp (a guess from what I found googling around). If I
> > configure /etc/security/limits.conf with
> >
> > testuser hard maxlogins 1
> >
> > and connect with ssh, and try a second connection with sftp, the sftp
> > fails because there is already one session open. But if I connect with
> > sftp and try a second sftp connection, it is allowed.
> >
> > Is there some way to have sftp connections recorded in utmp? I haven't
> > found any reference to this. There are some posts from 10+ years ago
> > where others were trying the same thing but there's no reply about how
> > to do it. Would it be possible to add this option?
>
> We've been asked about this a number of times before - the problem is
> that utmp is really set up to record interactive logins that have a
> TTY/PTY assigned. There is AFAIK no real standard for recording
> "service logins" (e.g. sftp or SSH command execution w/o TTY) in utmp
> and many OS utmp implementation lack fields by which this could be
> communicated.
>
> IIRC we toyed with recording something fake like "sftp" in ut_line
> but that caused problems as none of the other tools were set up to
> accept it.

sftp has some awkward limitations, as does scp. It's why I prefer were
possible to use rsync-over-SSH, and we can restrict the rsync options
quite heavily. It's even possible to chroot wrap, though that toolkit
has not been well maintained.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: sftp and utmp [ In reply to ]

Apr 4, 2023, 3:10 AM

Post #18 of 20 (1101 views)

On Tue, 4 Apr 2023, Nico Kadel-Garcia wrote:

> > We've been asked about this a number of times before - the problem is
> > that utmp is really set up to record interactive logins that have a
> > TTY/PTY assigned. There is AFAIK no real standard for recording
> > "service logins" (e.g. sftp or SSH command execution w/o TTY) in utmp
> > and many OS utmp implementation lack fields by which this could be
> > communicated.
> >
> > IIRC we toyed with recording something fake like "sftp" in ut_line
> > but that caused problems as none of the other tools were set up to
> > accept it.
>
> sftp has some awkward limitations, as does scp. It's why I prefer were
> possible to use rsync-over-SSH, and we can restrict the rsync options
> quite heavily. It's even possible to chroot wrap, though that toolkit
> has not been well maintained.

rsync doesn't solve the problem being presented here, as it runs without
a PTY and so never ends up being recorded in utmp either.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: sftp and utmp [ In reply to ]

nkadel at gmail

Apr 4, 2023, 1:42 PM

Post #19 of 20 (1094 views)

On Tue, Apr 4, 2023 at 6:10?AM Damien Miller <djm@mindrot.org> wrote:
>
> On Tue, 4 Apr 2023, Nico Kadel-Garcia wrote:
>
> > > We've been asked about this a number of times before - the problem is
> > > that utmp is really set up to record interactive logins that have a
> > > TTY/PTY assigned. There is AFAIK no real standard for recording
> > > "service logins" (e.g. sftp or SSH command execution w/o TTY) in utmp
> > > and many OS utmp implementation lack fields by which this could be
> > > communicated.
> > >
> > > IIRC we toyed with recording something fake like "sftp" in ut_line
> > > but that caused problems as none of the other tools were set up to
> > > accept it.
> >
> > sftp has some awkward limitations, as does scp. It's why I prefer were
> > possible to use rsync-over-SSH, and we can restrict the rsync options
> > quite heavily. It's even possible to chroot wrap, though that toolkit
> > has not been well maintained.
>
> rsync doesn't solve the problem being presented here, as it runs without
> a PTY and so never ends up being recorded in utmp either.

rsync over SSH can be configured in sshd_config to record the use of
public SSH keys. I don't normally set up such a restricted service on
the standard SSH daemon or the standard SSH port, mostly to keep the
logs very distinct.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: sftp and utmp [ In reply to ]

Apr 4, 2023, 4:17 PM

Post #20 of 20 (1091 views)

On Tue, 4 Apr 2023, Nico Kadel-Garcia wrote:

> On Tue, Apr 4, 2023 at 6:10?AM Damien Miller <djm@mindrot.org> wrote:
> >
> > On Tue, 4 Apr 2023, Nico Kadel-Garcia wrote:
> >
> > > sftp has some awkward limitations, as does scp. It's why I prefer were
> > > possible to use rsync-over-SSH, and we can restrict the rsync options
> > > quite heavily. It's even possible to chroot wrap, though that toolkit
> > > has not been well maintained.
> >
> > rsync doesn't solve the problem being presented here, as it runs without
> > a PTY and so never ends up being recorded in utmp either.
>
> rsync over SSH can be configured in sshd_config to record the use of
> public SSH keys. I don't normally set up such a restricted service on
> the standard SSH daemon or the standard SSH port, mostly to keep the
> logs very distinct.

Sure, but so can sftp-server (or any connection really, via a number of
methods).
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev