On 2019-12-10, Adam Thompson wrote:
> Is there a way to placate security(8) that I'm just not seeing? Or is
> my goal fundamentally misguided for some reason I'm not seeing? The
Philipp is right, * in master.passwd's crypted password field.
> user in this case is semi-trusted
Le mar. 10 déc. 2019 à 16:52, Adam Thompson a écrit :
>
> Is there a way to placate security(8) that I'm just not seeing? Or is
> my goal fundamentally misguided for some reason I'm not seeing? The
> user in this case is semi-trusted (e.g. yes, we'll let you login using
> an unprivileged
Evan Silberman writes:
> Why not assign a long, random password and then not share it with the
> user?
Or you can set your encrypted password to "*" as it is done for other
daemon users. You can use chpass(1) for this.
--
Manuel Giraud
Am 10.12.2019 17:07 schrieb Evan Silberman:
Is there a way to placate security(8) that I'm just not seeing? Or is
my goal fundamentally misguided for some reason I'm not seeing? The
user in this case is semi-trusted (e.g. yes, we'll let you login using
an unprivileged account to run bgpctl
> On Dec 10, 2019, at 7:55 AM, Adam Thompson wrote:
>
> Hi,
> On 6.6-STABLE, I'm looking at security(8) and it's not immediately obvious to
> me how I can have an SSH key-only user who does not have a password, that
> also does not trigger daily security warnings.
>
> The goal is to have
Hi,
On 6.6-STABLE, I'm looking at security(8) and it's not immediately
obvious to me how I can have an SSH key-only user who does not have a
password, that also does not trigger daily security warnings.
The goal is to have a user that can never log in on the console, or via
password any
6 matches
Mail list logo
