Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #225809 > unrolled thread

[OT] sudo: restrict to physical console only?

Back to article view | Back to linux.debian.user

Contents

  [OT] sudo: restrict to physical console only? Marco Möller <talby@debianlists.mobilxpress.net> - 2020-08-04 09:50 +0200
    Re: [OT] sudo: restrict to physical console only? <tomas@tuxteam.de> - 2020-08-04 11:00 +0200
      Re: [OT] sudo: restrict to physical console only? Marco Möller <talby@debianlists.mobilxpress.net> - 2020-08-04 11:50 +0200
        Re: [OT] sudo: restrict to physical console only? <tomas@tuxteam.de> - 2020-08-04 12:20 +0200
        Re: [OT] sudo: restrict to physical console only? Greg Wooledge <wooledg@eeg.ccf.org> - 2020-08-04 13:50 +0200
          Re: [OT] sudo: restrict to physical console only? Marco Möller <talby@debianlists.mobilxpress.net> - 2020-08-04 14:30 +0200
          Re: [OT] sudo: restrict to physical console only? <tomas@tuxteam.de> - 2020-08-04 15:10 +0200
            Re: [OT] sudo: restrict to physical console only? John Hasler <jhasler@newsguy.com> - 2020-08-04 17:30 +0200
              Re: [OT] sudo: restrict to physical console only? <tomas@tuxteam.de> - 2020-08-04 19:00 +0200
        Re: [OT] sudo: restrict to physical console only? Henning Follmann <hfollmann@itcfollmann.com> - 2020-08-04 16:00 +0200
          Re: [OT] sudo: restrict to physical console only? Marco Möller <talby@debianlists.mobilxpress.net> - 2020-08-04 16:10 +0200
            Re: [OT] sudo: restrict to physical console only? Michael Stone <mstone@debian.org> - 2020-08-04 17:10 +0200
    Re: [OT] sudo: restrict to physical console only? Keith bainbridge <keithrbau@gmail.com> - 2020-08-04 11:00 +0200
      Re: [OT] sudo: restrict to physical console only? Marco Möller <talby@debianlists.mobilxpress.net> - 2020-08-04 11:10 +0200
    Re: [OT] sudo: restrict to physical console only? Andy Smith <andy@strugglers.net> - 2020-08-04 18:50 +0200
    Re: [OT] sudo: restrict to physical console only? Reco <recoverym4n@enotuniq.net> - 2020-08-04 20:50 +0200
      Re: [OT] sudo: restrict to physical console only? Dan Ritter <dsr@randomstring.org> - 2020-08-04 22:30 +0200
        Re: [OT] sudo: restrict to physical console only? Reco <recoverym4n@enotuniq.net> - 2020-08-05 08:40 +0200

#225809 — [OT] sudo: restrict to physical console only?

Is it possible (how?) to restrict a user to only be allowed to make use 
of its sudo usage permission if working at the physical console, not 
granting to this user sudo permission when i.e. logged in via ssh? To 
keep it simple, I could imagine to even have all sudo for all users 
deactivated automatically as soon as a remote connection by ANY user is 
detected.
The idea behind this: I have the root account already deactivated, and 
am using in principal only one main user who also has the sudo 
permissions for being able to do all the system administration, exactly 
as Debian was setting this up automatically during the system 
installation. If I now this main user ssh access to the system, then I 
would like to asure that some security is in place, at least concerning 
such simple restrictions like not offering sudo. Coming physically back 
to the system could then be checked in the log files if meanwhile 
unwanted ssh login or activity took place because I assume that at least 
the log files cannot have been manipulated.

[toc] | [next] | [standalone]

#225814

[Multipart message — attachments visible in raw view] — view raw

On Tue, Aug 04, 2020 at 09:47:24AM +0200, Marco Möller wrote:
> Is it possible (how?) to restrict a user to only be allowed to make
> use of its sudo usage permission if working at the physical console,

See pam_securetty(8) for that. Sorry I can't give you some step-by-step
account.

> not granting to this user sudo permission when i.e. logged in via
> ssh?

Now you have to decide: You want to *only allow root login on console*
or to *disallow root login for ssh*?

For the first, PAM is the right tool. The second should be default on
most modern Linux distros (yell at them if it ain't ;-) and is governed
by the sshd configuration, typically in /etc/ssh/sshd_config and
documented in sshd_config(5).

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#225818

On 04.08.20 10:59, tomas@tuxteam.de wrote:
> On Tue, Aug 04, 2020 at 09:47:24AM +0200, Marco Möller wrote:
>> Is it possible (how?) to restrict a user to only be allowed to make
>> use of its sudo usage permission if working at the physical console,
> 
> See pam_securetty(8) for that. Sorry I can't give you some step-by-step
> account.
> 
>> not granting to this user sudo permission when i.e. logged in via
>> ssh?
> 
> Now you have to decide: You want to *only allow root login on console*
> or to *disallow root login for ssh*?
> 
> For the first, PAM is the right tool. The second should be default on
> most modern Linux distros (yell at them if it ain't ;-) and is governed
> by the sshd configuration, typically in /etc/ssh/sshd_config and
> documented in sshd_config(5).
> 
> Cheers
>   - t
> 

Sorry, I will not have been clear enough, or did not understand your 
answer clearly, ssh and pam are both new to me, and I also never 
configured sudo myself.
As my root account is disabled, I do all administration as the "normal" 
user with the help of sudo for running administrative commands. The user 
"root" shall not login nowhere, not at the physical console and not by 
ssh, never. Only the "normal" user should be allowed to log in to the 
system. The "normal" user then of course needs to keep the right to use 
"sudo" if working at the physical console (being logged in at a console 
(CTRL+ALT+F2), or logged in via sddm or gdm, or having opened a terminal 
within the X11 or Wayland session, etc.), but for security the access 
for this "normal" user to "sudo" privileges shall not be granted if this 
user would work at the system from remote, for instance logged in via ssh.
I could imagine that it is possible to kind of generally block all sudo 
(and also su) functionality in the system for everybody as soon as any 
remote (incoming) login to ssh is detected, and automatically allowing 
sudo functionality again if no more incoming ssh to the computer exists:
if remote (incoming) connection established, then disable sudo and su
if no remote (incoming) connection established, then switch on sudo and su
If such security mechanism could be done in a reliable way to only 
effect the incoming connection, while a parallel local (physically 
sitting at the computer) user could continue to work with sudo, then 
this would be fine, but assuming that this might be much more difficult 
to configure, especially if remote login and physical login could be the 
same user (same user ID), I am open to the drastic but simple version as 
described above.

[toc] | [prev] | [next] | [standalone]

#225819

[Multipart message — attachments visible in raw view] — view raw

On Tue, Aug 04, 2020 at 11:44:04AM +0200, Marco Möller wrote:
> On 04.08.20 10:59, tomas@tuxteam.de wrote:

[pam sshd]

> Sorry, I will not have been clear enough, or did not understand your
> answer clearly, ssh and pam are both new to me, and I also never
> configured sudo myself.

Ah, got it. Then sudo is your first stop :-)

It's configured via /etc/sudoers.conf (there is a special command
to edit that file). Proceed with care, since botching it might
make it more difficult to access your box :-)

Not all is lost, however if something goes awry.

The relevant documentation is in sudoers(5). I think you are
looking for 'requiretty', there, although I'm not sure whether
that will be as restrictive as you envision. Perhaps you need
to tweak your PAM setup for that as well.

Sorry for just providing generic pointers. I'd have to experiment
around to be more concrete, but I currently try to avoid rabbit
holes...

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#225821

On Tue, Aug 04, 2020 at 11:44:04AM +0200, Marco Möller wrote:
> As my root account is disabled, I do all administration as the "normal" user
> with the help of sudo for running administrative commands. The user "root"
> shall not login nowhere, not at the physical console and not by ssh, never.

Remember that this also means you can never boot in single-user ("rescue")
mode.  If you ever need to boot in quasi-rescue mode, you'll have to
go down even lower and override the init= kernel parameter.

If you don't know what that means, you should NOT be doing this.

[toc] | [prev] | [next] | [standalone]

#225822

On 04.08.20 13:39, Greg Wooledge wrote:
> On Tue, Aug 04, 2020 at 11:44:04AM +0200, Marco Möller wrote:
>> As my root account is disabled, I do all administration as the "normal" user
>> with the help of sudo for running administrative commands. The user "root"
>> shall not login nowhere, not at the physical console and not by ssh, never.
> 
> Remember that this also means you can never boot in single-user ("rescue")
> mode.  If you ever need to boot in quasi-rescue mode, you'll have to
> go down even lower and override the init= kernel parameter.
> 
> If you don't know what that means, you should NOT be doing this.
> 

Thanks for this warning, especially as this is a public mailing list and 
others might find this thread.
Fortunately I know already how to help me with the proper init=... boot 
parameter, which reminds me that I should check if this important detail 
is also mentioned in the Debian installation documentation or could be 
added there. I am afraid I have had to look it up elsewhere in the 
internet, when I needed it in the past, but am not sure about this 
detail anymore.

[toc] | [prev] | [next] | [standalone]

#225825

[Multipart message — attachments visible in raw view] — view raw

On Tue, Aug 04, 2020 at 07:39:53AM -0400, Greg Wooledge wrote:
> On Tue, Aug 04, 2020 at 11:44:04AM +0200, Marco Möller wrote:
> > As my root account is disabled, I do all administration as the "normal" user
> > with the help of sudo for running administrative commands. The user "root"
> > shall not login nowhere, not at the physical console and not by ssh, never.
> 
> Remember that this also means you can never boot in single-user ("rescue")
> mode.

Right. As someone who actually likes and uses sudo (not everyone does,
and there are good reasons to dislike it), this was one of my main
critiques of that "root-less" scheme. Sitting in front of a console
telling you that / is mounted ro and to enter your root password when
you haven't one can be... frustrating :-)

OTOH practice has shown: if you're doing sudo, you will have forgotten
your root password anyway when you need it (I have, it's some horrible
"pwgen -n 16" or something), and it' back to...

> If you ever need to boot in quasi-rescue mode, you'll have to
> go down even lower and override the init= kernel parameter.

... or to some rescue image.

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#225838

tomas writes:
> OTOH practice has shown: if you're doing sudo, you will have forgotten
> your root password anyway when you need it (I have, it's some horrible
> "pwgen -n 16" or something), and it' back to...

It should be written down somewhere secure.  Depending on your threat
model this can be on a note taped to the inside of the machine, in your
safe, or even in the notebook where you keep all your other passwords.
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#225847

[Multipart message — attachments visible in raw view] — view raw

On Tue, Aug 04, 2020 at 10:24:16AM -0500, John Hasler wrote:
> tomas writes:
> > OTOH practice has shown: if you're doing sudo, you will have forgotten
> > your root password anyway when you need it (I have, it's some horrible
> > "pwgen -n 16" or something), and it' back to...
> 
> It should be written down somewhere secure.  Depending on your threat
> model this can be on a note taped to the inside of the machine, in your
> safe, or even in the notebook where you keep all your other passwords.

It's in a file on the encrypted harddisk. Now you may ask... ;-)

Yes, of course. It's in a backup, on an (also) encrypted medium. But all
those possibilities (the ones you mention no less) mean that "init=/bin/sh"
or rescue medium are less work (I haven't a safe).

This is the point I was trying to make: a password you don't use often
isn't that useful if there are perfectly viable alternatives. Thus, /if/
you are using sudo, root password loses much of its glamour. This is
something I learnt slowly.

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#225827

On Tue, Aug 04, 2020 at 11:44:04AM +0200, Marco Möller wrote:
> On 04.08.20 10:59, tomas@tuxteam.de wrote:
> > On Tue, Aug 04, 2020 at 09:47:24AM +0200, Marco Möller wrote:
> > > Is it possible (how?) to restrict a user to only be allowed to make
> > > use of its sudo usage permission if working at the physical console,
> > 
> > See pam_securetty(8) for that. Sorry I can't give you some step-by-step
> > account.
> > 
> > > not granting to this user sudo permission when i.e. logged in via
> > > ssh?
> > 
> > Now you have to decide: You want to *only allow root login on console*
> > or to *disallow root login for ssh*?
> > 
> > For the first, PAM is the right tool. The second should be default on
> > most modern Linux distros (yell at them if it ain't ;-) and is governed
> > by the sshd configuration, typically in /etc/ssh/sshd_config and
> > documented in sshd_config(5).
> > 
> > Cheers
> >   - t
> > 
> 
> Sorry, I will not have been clear enough, or did not understand your answer
> clearly, ssh and pam are both new to me, and I also never configured sudo
> myself.
> As my root account is disabled, I do all administration as the "normal" user
> with the help of sudo for running administrative commands. The user "root"
> shall not login nowhere, not at the physical console and not by ssh, never.
> Only the "normal" user should be allowed to log in to the system. The
> "normal" user then of course needs to keep the right to use "sudo" if
> working at the physical console (being logged in at a console (CTRL+ALT+F2),
> or logged in via sddm or gdm, or having opened a terminal within the X11 or
> Wayland session, etc.), but for security the access for this "normal" user
> to "sudo" privileges shall not be granted if this user would work at the
> system from remote, for instance logged in via ssh.
> I could imagine that it is possible to kind of generally block all sudo (and
> also su) functionality in the system for everybody as soon as any remote
> (incoming) login to ssh is detected, and automatically allowing sudo
> functionality again if no more incoming ssh to the computer exists:
> if remote (incoming) connection established, then disable sudo and su
> if no remote (incoming) connection established, then switch on sudo and su
> If such security mechanism could be done in a reliable way to only effect
> the incoming connection, while a parallel local (physically sitting at the
> computer) user could continue to work with sudo, then this would be fine,
> but assuming that this might be much more difficult to configure, especially
> if remote login and physical login could be the same user (same user ID), I
> am open to the drastic but simple version as described above.
>

Have you considered to have one account allowed to ssh in and
one account allowed to sudo?

You say you are the only user. That seems like an simple
solution.


-H



-- 
Henning Follmann           | hfollmann@itcfollmann.com

[toc] | [prev] | [next] | [standalone]

#225831

On 04.08.20 15:50, Henning Follmann wrote:
> On Tue, Aug 04, 2020 at 11:44:04AM +0200, Marco Möller wrote:
>> On 04.08.20 10:59, tomas@tuxteam.de wrote:
>>> On Tue, Aug 04, 2020 at 09:47:24AM +0200, Marco Möller wrote:
>>>> Is it possible (how?) to restrict a user to only be allowed to make
>>>> use of its sudo usage permission if working at the physical console,
>>>
>>> See pam_securetty(8) for that. Sorry I can't give you some step-by-step
>>> account.
>>>
>>>> not granting to this user sudo permission when i.e. logged in via
>>>> ssh?
>>>
>>> Now you have to decide: You want to *only allow root login on console*
>>> or to *disallow root login for ssh*?
>>>
>>> For the first, PAM is the right tool. The second should be default on
>>> most modern Linux distros (yell at them if it ain't ;-) and is governed
>>> by the sshd configuration, typically in /etc/ssh/sshd_config and
>>> documented in sshd_config(5).
>>>
>>> Cheers
>>>    - t
>>>
>>
>> Sorry, I will not have been clear enough, or did not understand your answer
>> clearly, ssh and pam are both new to me, and I also never configured sudo
>> myself.
>> As my root account is disabled, I do all administration as the "normal" user
>> with the help of sudo for running administrative commands. The user "root"
>> shall not login nowhere, not at the physical console and not by ssh, never.
>> Only the "normal" user should be allowed to log in to the system. The
>> "normal" user then of course needs to keep the right to use "sudo" if
>> working at the physical console (being logged in at a console (CTRL+ALT+F2),
>> or logged in via sddm or gdm, or having opened a terminal within the X11 or
>> Wayland session, etc.), but for security the access for this "normal" user
>> to "sudo" privileges shall not be granted if this user would work at the
>> system from remote, for instance logged in via ssh.
>> I could imagine that it is possible to kind of generally block all sudo (and
>> also su) functionality in the system for everybody as soon as any remote
>> (incoming) login to ssh is detected, and automatically allowing sudo
>> functionality again if no more incoming ssh to the computer exists:
>> if remote (incoming) connection established, then disable sudo and su
>> if no remote (incoming) connection established, then switch on sudo and su
>> If such security mechanism could be done in a reliable way to only effect
>> the incoming connection, while a parallel local (physically sitting at the
>> computer) user could continue to work with sudo, then this would be fine,
>> but assuming that this might be much more difficult to configure, especially
>> if remote login and physical login could be the same user (same user ID), I
>> am open to the drastic but simple version as described above.
>>
> 
> Have you considered to have one account allowed to ssh in and
> one account allowed to sudo?
> 
> You say you are the only user. That seems like an simple
> solution.
> 
> 
> -H


Yes, I understand that this could ease configuration, but my thoughts 
are going towards a setup in which I access my computer from remote in 
order to enjoy the Graphical Desktop System and all software being 
nicely configured already, the home directory has my data available for 
me, etc. To this end I thought to maybe tunnel X11 through ssh, or using 
X2Go, or something alike. I am not sure about all this by now, I am 
still collecting information about the security part of all this.
The idea of Tomas to look in /etc/sudoers.conf for something like 
'requiretty' sounds promising. I will need a couple of days to read and 
learn about this and then testing it.
Marco

[toc] | [prev] | [next] | [standalone]

#225835

On Tue, Aug 04, 2020 at 04:09:30PM +0200, Marco Möller wrote:
>The idea of Tomas to look in /etc/sudoers.conf for something like 
>'requiretty' sounds promising. I will need a couple of days to read 
>and learn about this and then testing it.

That won't work. Anything that's based on identifying a "safe" tty won't 
work on a modern system. (In the old days you could identify a trusted 
tty by tracing its physical attachment. So /etc/securetty made sense 
because it was those terminals whose serial cables terminated in secure 
areas or which were directly attached, like the linux text console. But 
once X came along people wanted to use virtual terminals--at which point 
the idea of a secure physically-connected terminal went right out the 
Xwindow.) To get similar functionality now, you'd need something that 
has a concept of what is a local login vs what is a remote login. You 
could experiment with using systemd/polkit to do this, for example. 
*BUT* this approach is more inherently fragile, and it would be really 
good to make sure you have an actual root password to facilite recovery, 
as someone suggested earlier.

[toc] | [prev] | [next] | [standalone]

#225815

On 4/8/20 5:47 pm, Marco Möller wrote:
> I have the root account already deactivated, and am using in principal 
> only one main user who also has the sudo permissions for being able to 
> do all the system administration, exactly as Debian was setting this up 
> automatically during the system installation.


Mmmmm    I have ALWAYS been asked for a root password at debian 
installation. Is this behaviour new in the last 3-4 weeks?

The installer activates sudo only if you left root password blank - your 
choice; not default.

-- 

Keith Bainbridge

keithrbau@gmail.com

0447 667468

[toc] | [prev] | [next] | [standalone]

#225816

On 04.08.20 10:38, Keith bainbridge wrote:
> On 4/8/20 5:47 pm, Marco Möller wrote:
>> I have the root account already deactivated, and am using in principal 
>> only one main user who also has the sudo permissions for being able to 
>> do all the system administration, exactly as Debian was setting this 
>> up automatically during the system installation.
> 
> 
> Mmmmm    I have ALWAYS been asked for a root password at debian 
> installation. Is this behaviour new in the last 3-4 weeks?
> 
> The installer activates sudo only if you left root password blank - your 
> choice; not default.
> 

I left the root password blank, in order to not have the root account 
activated and to receive the sudo configuration automatically for my 
one, main, "normal" user. Maybe not default, but done following the 
official documentation offering this option for consideration (I do not 
have the exact reference available right now, but I am sure to have 
followed and received knowledge about this option from documentation 
published on the Debian site, most likely even from the installation 
manual itself).

[toc] | [prev] | [next] | [standalone]

#225846

Hi Marco,

On Tue, Aug 04, 2020 at 09:47:24AM +0200, Marco Möller wrote:
> Is it possible (how?) to restrict a user to only be allowed to make use of
> its sudo usage permission if working at the physical console, not granting
> to this user sudo permission when i.e. logged in via ssh?

I was intrigued by this question so I tried to find out how to do
it. I was unsuccessful and only got as far as:

    https://www.sudo.ws/pipermail/sudo-users/2009-April/004015.html

Probably the feature has not been added to sudo in the last 11 years
either.

Perhaps using pam_group.so you could force users on certain ttys
into a specific group, and allow that group (only) to use sudo?

    http://www.linux-pam.org/Linux-PAM-html/sag-pam_group.html

I've never done it but the above seems to imply that putting
something like:

     *;tty*;*;*;mysudogroup

into /etc/security/group.conf would put any user logging in on tty*
into the group "mysudogroup". If you allowed "mysudogroup" to use
sudo in /etc/sudoers then maybe that works.

I would be interested to know if that is a workable solution.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#225853

	Hi.

On Tue, Aug 04, 2020 at 09:47:24AM +0200, Marco Möller wrote:
> Is it possible (how?) to restrict a user to only be allowed to make use of its sudo usage permission if working at the physical console, not granting to this
> user sudo permission when i.e. logged in via ssh? To keep it simple, I could imagine to even have all sudo for all users deactivated automatically as soon as
> a remote connection by ANY user is detected.

Yes. It's an unusual (some may say - dangerous) thing that you're
asking, so prepare to the unusual side effects.

--- a/etc/pam.d/sudo   2020-08-04 18:40:26.528699633 +0000
+++ b/etc/pam.d/sudo   2020-08-04 18:40:26.296579395 +0000
@@ -1,5 +1,6 @@
 #%PAM-1.0

 @include common-auth
+auth required pam_succeed_if.so tty =~ /dev/tty*
 @include common-account
 @include common-session-noninteractive


I'm assuming that by "physical console" you mean that lovely
conventional virtual terminal kernel facility (i.e. that funny letters
that appear on your screen then you press Ctrl+Alt+F2). Be warned that
in the current form it *will* break sudo for anyone, root included, for
any process which "tty" attribute does not match /dev/tty*, be it ssh,
screen, tmux, and (possibly) X/Wayland sessions.
Worked for me in the case of real servers, just in case.

Reco

[toc] | [prev] | [next] | [standalone]

#225858

Reco wrote: 
> 	Hi.
> 
> On Tue, Aug 04, 2020 at 09:47:24AM +0200, Marco M?ller wrote:
> > Is it possible (how?) to restrict a user to only be allowed to make use of its sudo usage permission if working at the physical console, not granting to this
> > user sudo permission when i.e. logged in via ssh? To keep it simple, I could imagine to even have all sudo for all users deactivated automatically as soon as
> > a remote connection by ANY user is detected.
> 
> Yes. It's an unusual (some may say - dangerous) thing that you're
> asking, so prepare to the unusual side effects.
> 
> --- a/etc/pam.d/sudo   2020-08-04 18:40:26.528699633 +0000
> +++ b/etc/pam.d/sudo   2020-08-04 18:40:26.296579395 +0000
> @@ -1,5 +1,6 @@
>  #%PAM-1.0
> 
>  @include common-auth
> +auth required pam_succeed_if.so tty =~ /dev/tty*
>  @include common-account
>  @include common-session-noninteractive
> 
> 
> I'm assuming that by "physical console" you mean that lovely
> conventional virtual terminal kernel facility (i.e. that funny letters
> that appear on your screen then you press Ctrl+Alt+F2). Be warned that
> in the current form it *will* break sudo for anyone, root included, for
> any process which "tty" attribute does not match /dev/tty*, be it ssh,
> screen, tmux, and (possibly) X/Wayland sessions.
> Worked for me in the case of real servers, just in case.
 
It should also match for serial connections, including modem users,
should you have any of such. And USB serial terminals.

-dsr-

[toc] | [prev] | [next] | [standalone]

#225870

	Hi.

On Tue, Aug 04, 2020 at 04:20:58PM -0400, Dan Ritter wrote:
> Reco wrote: 
> > On Tue, Aug 04, 2020 at 09:47:24AM +0200, Marco M?ller wrote:
> > > Is it possible (how?) to restrict a user to only be allowed to make use of its sudo usage permission if working at the physical console, not granting to this
> > > user sudo permission when i.e. logged in via ssh? To keep it simple, I could imagine to even have all sudo for all users deactivated automatically as soon as
> > > a remote connection by ANY user is detected.
> > 
> > Yes. It's an unusual (some may say - dangerous) thing that you're
> > asking, so prepare to the unusual side effects.
> > 
> > --- a/etc/pam.d/sudo   2020-08-04 18:40:26.528699633 +0000
> > +++ b/etc/pam.d/sudo   2020-08-04 18:40:26.296579395 +0000
> > @@ -1,5 +1,6 @@
> >  #%PAM-1.0
> > 
> >  @include common-auth
> > +auth required pam_succeed_if.so tty =~ /dev/tty*
> >  @include common-account
> >  @include common-session-noninteractive
> > 
> > 
> > I'm assuming that by "physical console" you mean that lovely
> > conventional virtual terminal kernel facility (i.e. that funny letters
> > that appear on your screen then you press Ctrl+Alt+F2). Be warned that
> > in the current form it *will* break sudo for anyone, root included, for
> > any process which "tty" attribute does not match /dev/tty*, be it ssh,
> > screen, tmux, and (possibly) X/Wayland sessions.
> > Worked for me in the case of real servers, just in case.
>  
> It should also match for serial connections, including modem users,
> should you have any of such. And USB serial terminals.

I consider it a feature, not a deficiency. It cannot be called a server
unless it features a RS-232-based console connection typically assigned
to ttyS0, and locking myself out of it is not something that I'd do.
But, as they say, patches are welcome.

Reco

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web