Re: [gentoo-user] Any way to automate login to host and su to root?

[Grant Taylor]

On 7/15/22 4:11 PM, Neil Bothwick wrote:
I've never used it before, mainly because I wasn't aware of its 
existence until I re-read the ssh-keygen man page, but it seems to 
be simple timestamps passed to valid-before/valid-after.


I'm not sure that's applicable to /keys/ verses /certificates/.

Excerpt from the ssh-keygen man page:

-V validity_interval

Specify a validity interval when signing a /certificate/.  A validity 
interval may consist of a single time, indicating that the /certificate/ 
is valid beginning now and expiring at that time, or may consist of two 
times separated by a colon to indicate an explicit time interval.


Maybe there's something else, but it seems like the validity period is 
for SSH /certificates/ and not SSH /keys/.




--
Grant. . . .
unix || die

Re: [gentoo-user] Is there a way to screenshare under wayland in firefox (using jitsi) without installing PipeWire?

[Jack]

On 2022.07.14 18:51, Dex Conner wrote:

Hi all,

I use wayland and I need to screenshare on jitsi. It uses WebRTC to
screenshare. I don't have PipeWire and use just ALSA instead (running
apulse for firefox). Is there any way for me to screenshare without
installing PipeWire?

Thank you!

--
Dex
I suspect you may get more information on the jitsi community forum:  
https://community.jitsi.org/.  I just tried starting Wayland, and  
although a basic connection to my jitsi server worked, firefox seemed  
to think it was sharing the screen (although I don't recall it asking  
which window or screen to share.) It didn't work in chromium either,  
but again, there was no real error or indication there was a problem,  
just no sharing.  I'm running Pulseadio, but do not have pipewire  
installed.


Jack

Re: [gentoo-user] Any way to automate login to host and su to root?

[Neil Bothwick]

On Fri, 15 Jul 2022 13:33:45 -0600, Grant Taylor wrote:

> > I'll check that out, but it is also possible to set time limits on SSH
> > keys, and limit them to specific commands.  
> 
> Please elaborate on the time limit capability of SSH /keys/.  I wasn't 
> aware of that.
> 
> Is it hours of the day / days of the week they can be used?  Or is it 
> the number of days / date range that they can be used?

I've never used it before, mainly because I wasn't aware of its existence
until I re-read the ssh-keygen man page, but it seems to be simple
timestamps passed to valid-before/valid-after.


-- 
Neil Bothwick

"If you can't explain it simply, you don't understand it well enough."
 (Albert Einstein)


pgpQq_7KCI1P3.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Google Chrome now requires wayland and jack audio?

[Mark Knecht]

On Fri, Jul 15, 2022 at 1:56 PM Grant Edwards 
wrote:
>
> On 2022-07-15, Mark Knecht  wrote:
> > On Fri, Jul 15, 2022 at 12:28 PM Grant Edwards <
grant.b.edwa...@gmail.com>
> > wrote:

> > I'm curious as the USB disconnect problem seems somehow to be
> > related to using Chrome on the host machine for sites that do a lot
> > of audio, like YouTube. A clean boot of the host machine, followed
> > by a clean boot of the VM and I've run for at least an hour with no
> > disconnection problems. I can use Chrome for email, messaging and
> > reading newspapers with no problem, but I run YouTube and twice I've
> > had USB problems in the VM.
>
>
> Yep, it sounds like doing audio via Chrome is disrupting the the USB
> audio device that's in-use by the VM. Are there Linux audio drivers
> for that hardware that you could uninstall to keep Chrome from seeing
> it?

There is no support in Linux for this hardware. From the computer's
POV it's just an external USB device, partially an audio device, and
partially just controlled over USB. I've told pulseaudio and KDE in
general not to use it but I continue to see problems. I have no idea
what functionality the USB control port is providing.

I think the next step is to actually blacklist the device by its
USB device ID ala something like this:

https://www.projectgus.com/2014/09/blacklisting-a-single-usb-device-from-linux/

and see what happens.

This whole thing isn't overly critical to me. The device itself is
stand alone in operation. It's only attached to a computer to do editing
which actually can be done on the device's GUI without a computer, or
I can hook it to a Windows laptop, or even this machine if booted into
Windows. I was just wanting to be in Linux but open a VM to allow
me to edit more easily, which I actually can do but I have to hit the
reconnect button in software or pull the USB cable, both of which
work but are hacks.

Re: [gentoo-user] Google Chrome now requires wayland and jack audio?

[Jigme Datse]

On Fri, 15 Jul 2022 19:28:07 - (UTC)
Grant Edwards  wrote:

> It looks like www-client/google-chrome just added wayland and jack
> audio to the dependancies. So now I have to have Pulse _and_ Jack?


Pipewire will allow you to handle both in a pretty seamless way.
Though it does take a bit of configuration to get it working.  


pgpyGiUSqwZYv.pgp
Description: OpenPGP digital signature

[gentoo-user] Re: Google Chrome now requires wayland and jack audio?

[Grant Edwards]

On 2022-07-15, Mark Knecht  wrote:
> On Fri, Jul 15, 2022 at 12:28 PM Grant Edwards 
> wrote:
>>
>> It looks like www-client/google-chrome just added wayland and jack
>> audio to the dependancies. So now I have to have Pulse _and_ Jack?

> Is that truly a Chrome requirement, like the company Google wrote
> the ebuild, or is this something a Gentoo dev did for some reason?

Google doesn't provide an ebuild. The ebuild is written maintained by
the kind volunteers of the Chromium in Gentoo Project. For the binary
distribution from Google, those devs have no control over what
libraries the Chrome executables are built to use. All they can do is
try to figure out which libraries Chrome needs, and reflect that in
the ebuild so that after the binary from Google gets installed, it
works.

That said, there was no jack audio requirement for Chrome. I misread
the emerge output. The two new requirements that google-chrome was
pulling in were

 dev-libs/wayland
 dev-util/wayland-scanner

You don't have to be running Wayland, but you now need the above
wayland pieces.

There isn't actually a pulse audio requirement in the google-chrome
ebuild either, but if I don't have pulse installed, some audio stuff
in Chrome doesn't work. In web apps like Google Voice

 * I can select my headset mic as audio in, but it won't work.

 * I can't select headset as audio out.

Installing pulse audio fixed those problems.

> I'm curious as the USB disconnect problem seems somehow to be
> related to using Chrome on the host machine for sites that do a lot
> of audio, like YouTube. A clean boot of the host machine, followed
> by a clean boot of the VM and I've run for at least an hour with no
> disconnection problems. I can use Chrome for email, messaging and
> reading newspapers with no problem, but I run YouTube and twice I've
> had USB problems in the VM.


Yep, it sounds like doing audio via Chrome is disrupting the the USB
audio device that's in-use by the VM. Are there Linux audio drivers
for that hardware that you could uninstall to keep Chrome from seeing
it?

--
Grant

[gentoo-user] Re: Google Chrome now requires wayland and jack audio?

[Grant Edwards]

On 2022-07-15, Julien Roy  wrote:

> One of the side effects of using proprietary software : you can't
> control with which flags it gets built.

Yep. I didn't used to have the chrome binary package installed, but
there are a couple things that I've never gotten to work in Chromium
(e.g. Webex).

> With chromium-bin, there is a wayland USE flag, but nothing for
> jack.

I looked into that more, and I had misread the emerge output. It
wasn't google-chrome that depended on jack, and now I can't figure out
why it was installed. I did

# emerge -C virtual/jack media-sound/jack-audio-connection-kit
# emerge -auvND world

It didn't get reinstalled. And then a subsequenct

# emerge --depclean --ask

removed another half-dozen audio-related packagets (zita-* and
realtime-*, whatever they are). I'm sure the next time I try to use
audio on that machine it won't work.

I used to think that someday Linux sound support would get
straightened out, but it just keeps getting worse...

--
Grant

Re: [gentoo-user] Google Chrome now requires wayland and jack audio?

[Mark Knecht]

On Fri, Jul 15, 2022 at 12:28 PM Grant Edwards 
wrote:
>
> It looks like www-client/google-chrome just added wayland and jack
> audio to the dependancies. So now I have to have Pulse _and_ Jack?
>
> --
> Grant

Is that truly a Chrome requirement, like the company Google wrote the
ebuild, or is
this something a Gentoo dev did for some reason?

I'm curious as the USB disconnect problem seems somehow to be related
to using Chrome on the host machine for sites that do a lot of audio, like
YouTube. A clean boot of the host machine, followed by a clean boot of the
VM
and I've run for at least an hour with no disconnection problems. I can use
Chrome for email, messaging and reading newspapers with no problem, but
I run YouTube and twice I've had USB problems in the VM.

Re: [gentoo-user] Google Chrome now requires wayland and jack audio?

[Julien Roy]

One of the side effects of using proprietary software : you can't 
control with which flags it gets built.

With chromium-bin, there is a wayland USE flag, but nothing for jack.

On 7/15/22 15:28, Grant Edwards wrote:

It looks like www-client/google-chrome just added wayland and jack
audio to the dependancies. So now I have to have Pulse _and_ Jack?

--
Grant








--
Julien


OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-user] Any way to automate login to host and su to root?

[Grant Taylor]

On 7/15/22 1:12 PM, Neil Bothwick wrote:

I'll check that out, but it is also possible to set time limits on SSH
keys, and limit them to specific commands.


Please elaborate on the time limit capability of SSH /keys/.  I wasn't 
aware of that.


Is it hours of the day / days of the week they can be used?  Or is it 
the number of days / date range that they can be used?




--
Grant. . . .
unix || die

[gentoo-user] Google Chrome now requires wayland and jack audio?

[Grant Edwards]

It looks like www-client/google-chrome just added wayland and jack
audio to the dependancies. So now I have to have Pulse _and_ Jack?

--
Grant

Re: [gentoo-user] Any way to automate login to host and su to root?

[Neil Bothwick]

On Fri, 15 Jul 2022 10:35:41 -0600, Grant Taylor wrote:

> > However, I will look at scripting regular replacements for SSH keys, 
> > for my own peace of mind.  
> /me loudly says "SSH /certificates/" from the top atop a pile of old 
> servers in the server room.

I'll check that out, but it is also possible to set time limits on SSH
keys, and limit them to specific commands.


-- 
Neil Bothwick

Do you steal taglines too?


pgpsF_1LXTk7J.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Any way to automate login to host and su to root?

[Grant Taylor]

On 7/14/22 3:22 PM, Steve Wilson wrote:

Have you looked at dev-tcltk/expect?


Expect has it's place.

Just be EXTREMELY careful when using it for anything security related.

Always check for what is expected before sending data.  Don't assume 
that something comes next and blindly send it (possibly after a pause).


Things break in a really weird and unexpected way.  (No pun intended.)

Also, do as much logic outside of expect as possible.  E.g. don't try to 
add a user and then respond to a failure.  Instead check to see if the 
user exists /before/ trying to add it.


Plan on things failing and try to control the likely ways that it can fail.

Paying yourself forward with time and effort developing (expect) scripts 
will mean that you reap the rewards for years to come.




--
Grant. . . .
unix || die

Re: [gentoo-user] Any way to automate login to host and su to root?

[Grant Taylor]

On 7/15/22 6:44 AM, Neil Bothwick wrote:

I don't share keys, each desktop/laptop has its own keys.




Not if they use their own keys. It should be simple to script 
generating a new key, then SSHing to a list of machines and replacing 
the old key with the new one in authorized_keys.


+1

Indeed it is, and now you've found a way to do what you want with 
passwords, all is well.


However, I will look at scripting regular replacements for SSH keys, 
for my own peace of mind.
/me loudly says "SSH /certificates/" from the top atop a pile of old 
servers in the server room.




--
Grant. . . .
unix || die

Re: [gentoo-user] Any way to automate login to host and su to root?

[Grant Taylor]

On 7/15/22 1:53 AM, J. Roeleveld wrote:

I agree, but that is a tedious process.


Yes, it can be.  That's where some automation comes into play.

I have multiple machines I use as desktop depending on where I am. And 
either I need to securely share the private keys between them or set 
up different keys per desktop.


I /currently/ use unique keys /per/ /client/ /system/.

I am /planing/ on starting to use unique keys /per/ /client/ /per/ 
/server/.  Meaning that each client will use a different key for each 
remote server.  I think that this combined with location restrictions in 
the authorized_keys file will mean that SSH keys (or certificates) can't 
be used from anywhere other than their approved location or for anything 
other than their intended purpose.



I assume the same is true for most people.


Yes.  It depends what security posture you / your organization want.

Never mind that access to the servers needs to be possible for others 
as well.


I assume that other users will use their own individual accounts to log 
into the target systems with a similar configuration.


E.g. I log into remote systems as "gtaylor" and you log into remote 
systems as "joost", and Neil logs into remote systems as "neil".  We 
would all then escalate to root via "su -" with the automation providing 
the password to su.


Either way, to do this automatically, all the desktop machines need 
to be powered and running while changing the keys.


No, they don't.

You just need to account for current and prior keys.

I've done exactly this on a fleet of about 800 Unix systems that I 
helped administer at my last job.  You do something like the following:


1)  Log into the remote system explicitly using the prior key.
2)  Append the current key to the ~/.ssh/authorized_keys file.
3)  Logout of the remote system.
4)  Log into the remote system explicitly using the current key.
5)  Remove the prior key from the ~/.ssh/authorized_keys file.
6)  Logout of the remote system.

This can be fairly easily automated.

You can then loop across systems using this automation to update the key 
on systems that are online.


You can relatively easily deal with systems that are offline currently 
later when they are back online.  --  There are ways to differentiate 
between offline and bad credentials during day to day operations.  So 
when you hit the bad credentials you leverage the automation that tries 
old credentials to update them.


You end up bifurcating the pool of systems into different groups that 
need to be dealt with differently.  Online and doing what you want; 
online but not doing what you want; and offline.


Changing passwords for servers and storing them in a password vault 
is easier to automate.


I disagree.

Using passwords tends to negate things like authenticating to sudo with 
SSH keys / certificates, thus prompting the use of NOPASSWD:.




--
Grant. . . .
unix || die

Re: [gentoo-user] Any way to automate login to host and su to root?

[Grant Taylor]

On 7/15/22 1:15 AM, J. Roeleveld wrote:

Yes.


Okay.

That simply means that SSH keys won't be used to authenticate to the 
remote system.



How would it not prompt for a password.


There is a PAM module; pam_ssh_agent_auth, which can be used to enable 
users to authenticate to sudo using SSH keys.  This means that the user 
/does/ authenticate to sudo as necessary.  It's just that the 
authentication happens behind the scenes and they don't need to enter 
their password.  Thus you can avoid the NOPASSWD: option which means a 
better security posture.


I need something that will take the password from the vault (I 
can do this in Python and shell-scripting. Probably also in other 
scripts). Authenticating to the vault can be done on a session basis 
and shared. So locally, I'd only login once.


Sure.

Currently, yes. I never physically see the password as it currently 
goes into the clipboard and gets wiped from there after a short time 
period. Enough time to paste it into the password-prompt. It's 
the copy/pasting that I am looking to automate into a single 
"login-to-remote-host" script.


I would not consider the copy and paste method to be secure.  There are 
plenty of utilities to monitor the clipboard et al. and copy the new 
contents in extremely short order.  As such, users could arrange to 
acquire copies of the password passing through the clipboard.


I would strongly suggest exploring options that don't use the clipboard 
and instead retrieve the password from the vault and inject it into the 
remote system without using the clipboard.


Or, authenticate to sudo a different way that doesn't involve a 
password.  This will work for 90+ percent of the use cases.  Meaning 
that the sensitive password is needed for 10 percent or less of the 
time.  Thereby reducing the possible sensitive password exposure.  }:-)


I prefer not to use SSH keys for this as they tend to exist for years 
in my experience. And one unnoticed leak can open up a lot of systems.


That is a valid concern.

I'd strongly suggest that you research SSH /certificates/.  SSH 
/certificates/ support a finite life time /and/ can specify what 
command(s) / action(s) they can be used for.


My $EMPLOYER uses SSH /certificates/ that last about 8 hours.  I've 
heard of others that use SSH /certificates/ that last for a single digit 
number of minutes or even seconds.  The idea being that the SSH 
/certificate/ only lasts just long enough for it to be used for it's 
intended purpose and no longer.


The ability to specify the command; e.g. "su -" that is allowed to be 
executed means that people can't use them to start any other command.  }:-)


This is why I use passwords. (passwords are long random strings that 
are changed regularly)


Fair enough.  I only counter with take a few minutes to research SSH 
/certificates/ and see if they are of any interest to you.




--
Grant. . . .
unix || die

Re: [gentoo-user] Any way to automate login to host and su to root?

[Grant Taylor]

On 7/15/22 1:07 AM, J. Roeleveld wrote:

What I am looking for is:
1) Lookup credentials from password vault (I can do this in 
script-form, already doing this in limited form for ansible-scripts, 
but this doesn't give me an interactive shell)


ACK  You indicated you already had a solution for this.  So I'm leaving 
it in your capable hands.



2) Use admin-account credentials to login via SSH into host


When you say "admin-account", do you mean the given System 
Administrator's personal account or a common / shared administrative 
account?  E.g. would I log in as myself; "gtaylor", or something shared 
"helpdeskadmin"?


I'm assuming the former unless corrected.

Do you want the user to be prompted for the Unix account password (on 
the remote system) or can they use SSH keys to login without a password 
prompt?


3) On remote host, initiate "su -" to switch to root and provide 
root-password over SSH link at the right time


I would suggest having the SSH command invoke the "su -" command 
automatically.


Note:  You will probably want to run a command something like this to 
make sure that a TTY is allocated for proper interaction with su.


ssh -t @ "/path/to/su -"


4) Give me an interactive root-shell on remote-host


Okay.  Not what I would have expected, but it's your system and you do 
you.  :-)


When I close the shell, I expect to be fully logged out (eg, I go 
straight back to the local host, not to the admin-account)


The nice thing about having SSH invoke the "su -" command directly is 
that once you exit su, you also end up exiting the SSH session.


I see plenty of google-results and also as answers for ssh directly to 
"root" using ssh-keys.  I do not consider this a safe method, I use 
it for un- priviliges accounts (not member of "wheel"). I don't use 
it for admin- accounts.


Thank you for the elaboration.  I tend to agree with your stance.  I 
have exceedingly few things that can SSH into systems as the root user, 
and they all have forced commands.  They all have to do with the backup 
system which can't use sudo /or/ I want the ability to get in and 
restore a sudoers file if it gets messed up, thus avoiding the chicken / 
egg problem.


Following the same security mentality, I prefer to specify the full path 
to executables, when possible, in order to make sure that someone 
doesn't put a Trojanized version earlier in the path.  }:-)




--
Grant. . . .
unix || die

Re: [gentoo-user] USB random disconnections in VB Win10 VM

[Mark Knecht]

On Thu, Jul 14, 2022 at 4:53 PM Mark Knecht  wrote:
>
>
>
>
> On Thu, Jul 14, 2022, 4:25 PM Wol  wrote:
> >
> > On 14/07/2022 18:42, Mark Knecht wrote:
> > > If instead I'm in Linux with a Win10 VM running I can run the same
> > > software in the VM, and it will always see the external DSP when first
> > > started, but at random times, generally 5-20 seconds but never more
than
> > > 5 minutes, the software will tell me the USB connection has been
> > > interrupted and I am forced in the software to reestablish a
connection.
> > > I am always able to reconnect but I am so far unable to keep it
connected.
> >
> > Is there a setting in VB to say "take over the USB port"? ISTR something
> > of the sort, which would basically let Win10 take over the port and
> > drive it, with linux out of the picture.
> >
> > Don't trust me on this, I don't play with USB and it's ages since I
> > stumbled across this, but it's worth taking a look.
> >
> > Cheers,
> > Wol
>
>
> Good questions. I'm not sure with USB. As I understand it there
> are options in Virtualbox to pass through complete pieces of hardware.
> I've read that people do this with complete graphics cards. In theory
> possibly it could be done with USB but my guess is it might be
> difficult as most USB controllers are part of the chipset. Still, it's
worth
> some study.
>
> As this DSP processor is identified as an audio device I wondered
> today if possibly pulseaudio might be trying to grab it. I intend to
> look into configuring PA not to touch it.
>
> There's also (possibly) blacklisting certain USB device IDs. In the
> VM I configured it to understand the device ID and hook to it.
> Possibly I can tell the Linux USB stack to ignore this device so that
> PA or some other part of the system just stays away.
>
> But being that the DSP device is an guitar amplifier modeler
> and my new Tele came back from my guitar tech at lunchtime
> I spent the afternoon playing the guitar! Nonproductive but fun!
>
> Thanks for the ideas,
> Mark

>
More or less solved this morning apparently. We'll see after more time
has elapsed.

My desktop environment is KDE. MY sound environment is then, by
default, pulseaudio. By disabling the DSP processor as a sound
device in KDE System Settings I've now been running the VM
and support software for about 90 minutes with only 1 disconnection
which came the very first time I did something in KDE (started a
new chrome window) after starting the control software in the VM.

Since then I have had no more disconnections.

I will have to see how it does over the rest of the day and weeks
ahead but it's certainly acting better right now.

Cheers,
Mark

Re: [gentoo-user] Any way to automate login to host and su to root?

[Neil Bothwick]

On Fri, 15 Jul 2022 09:53:44 +0200, J. Roeleveld wrote:

> > There's no reason you cannot change SSH keys as regularly, and good
> > reasons why you should. It's just that people don't bother to do it.  
> 
> I agree, but that is a tedious process.
> 
> I have multiple machines I use as desktop depending on where I am. And
> either I need to securely share the private keys between them or set up
> different keys per desktop.
> I assume the same is true for most people.

I don't share keys, each desktop/laptop has its own keys.
 
> Never mind that access to the servers needs to be possible for others
> as well.
> 
> Either way, to do this automatically, all the desktop machines need to
> be powered and running while changing the keys.

Not if they use their own keys. It should be simple to script generating
a new key, then SSHing to a list of machines and replacing the old key
with the new one in authorized_keys.

> Changing passwords for servers and storing them in a password vault is
> easier to automate.

Indeed it is, and now you've found a way to do what you want with
passwords, all is well.

However, I will look at scripting regular replacements for SSH keys, for
my own peace of mind.


-- 
Neil Bothwick

Mac screen message: "Like, dude, something went wrong."


pgpGAZfUYl3QJ.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Any way to automate login to host and su to root?

[J. Roeleveld]

On Friday, 15 July 2022 10:13:12 CEST J. Roeleveld wrote:
> On Thursday, 14 July 2022 23:22:46 CEST Steve Wilson wrote:
> > On 14/07/2022 07:35, J. Roeleveld wrote:
> > > Hi All,
> > > 
> > > I am looking for a way to login to a host and automatically change to
> > > root
> > > using a password provided by an external program.
> > > 
> > > The root passwords are stored in a vault and I can get passwords out
> > > using
> > > a script after authenticating.
> > > 
> > > Currently, I need to do a lot of the steps manually:
> > > ssh @
> > > su -
> > > (copy/paste password from vault)
> > > 
> > > I would like to change this to:
> > >  
> > > 
> > > Does anyone have any hints on how to achieve this without adding a
> > > "NOPASSWD" entry into /etc/sudoers ?
> > > 
> > > Thanks in advance,
> > > 
> > > Joost
> > 
> > Have you looked at dev-tcltk/expect?
> > 
> > There's possibly an example you could try at
> > 
> > although you probably want to prompt for the password or retreive it
> > programatically rather than putting it on the command line :o
> > 
> > Steve.
> 
> This looks promising. Will have a look to see if this can be made to work.
> I will need to find a way to get the password programmatically inside the
> script as I will not put it on the commandline and definitely not hard-coded
> in a script.

Thank you, this works.
Got the script to grab all the details needed from the vault and ends up 
giving me a remote root-prompt.

--
Joost

Re: [gentoo-user] Any way to automate login to host and su to root?

[J. Roeleveld]

On Thursday, 14 July 2022 23:22:46 CEST Steve Wilson wrote:
> On 14/07/2022 07:35, J. Roeleveld wrote:
> > Hi All,
> > 
> > I am looking for a way to login to a host and automatically change to root
> > using a password provided by an external program.
> > 
> > The root passwords are stored in a vault and I can get passwords out using
> > a script after authenticating.
> > 
> > Currently, I need to do a lot of the steps manually:
> > ssh @
> > su -
> > (copy/paste password from vault)
> > 
> > I would like to change this to:
> >  
> > 
> > Does anyone have any hints on how to achieve this without adding a
> > "NOPASSWD" entry into /etc/sudoers ?
> > 
> > Thanks in advance,
> > 
> > Joost

> Have you looked at dev-tcltk/expect?
> 
> There's possibly an example you could try at
> 
> although you probably want to prompt for the password or retreive it
> programatically rather than putting it on the command line :o
> 
> Steve.
> 

This looks promising. Will have a look to see if this can be made to work.
I will need to find a way to get the password programmatically inside the 
script as I will not put it on the commandline and definitely not hard-coded 
in a script.

--
Joost

Re: [gentoo-user] Any way to automate login to host and su to root?

[J. Roeleveld]

On Friday, 15 July 2022 09:29:14 CEST Neil Bothwick wrote:
> On Fri, 15 Jul 2022 09:15:02 +0200, J. Roeleveld wrote:
> > I prefer not to use SSH keys for this as they tend to exist for years
> > in my experience. And one unnoticed leak can open up a lot of systems.
> > This is why I use passwords. (passwords are long random strings that
> > are changed regularly)
> 
> There's no reason you cannot change SSH keys as regularly, and good
> reasons why you should. It's just that people don't bother to do it.

I agree, but that is a tedious process.

I have multiple machines I use as desktop depending on where I am. And either 
I need to securely share the private keys between them or set up different 
keys per desktop.
I assume the same is true for most people.

Never mind that access to the servers needs to be possible for others as well.

Either way, to do this automatically, all the desktop machines need to be 
powered and running while changing the keys.

Changing passwords for servers and storing them in a password vault is easier 
to automate.

--
Joost

Re: [gentoo-user] Any way to automate login to host and su to root?

[Neil Bothwick]

On Fri, 15 Jul 2022 09:15:02 +0200, J. Roeleveld wrote:

> I prefer not to use SSH keys for this as they tend to exist for years
> in my experience. And one unnoticed leak can open up a lot of systems.
> This is why I use passwords. (passwords are long random strings that
> are changed regularly)

There's no reason you cannot change SSH keys as regularly, and good
reasons why you should. It's just that people don't bother to do it.


-- 
Neil Bothwick

I don't suffer from insanity. I enjoy every minute of it.


pgpn7dwYB6oTY.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Any way to automate login to host and su to root?

[J. Roeleveld]

On Thursday, 14 July 2022 17:30:28 CEST Grant Taylor wrote:
> On 7/14/22 12:35 AM, J. Roeleveld wrote:
> > Hi All,
> 
> Hi,
> 
> > I am looking for a way to login to a host and automatically change
> > to root using a password provided by an external program.
> 
> Please clarify if you want to /require/ a password?

Yes.

> I can think of some options that would authenticate, thus avoiding
> sudo's NOPASSWD:, but not prompt for a password.  I want to know if
> those types of options are on the table or if they should be discarded.

How would it not prompt for a password. I need something that will take the 
password from the vault (I can do this in Python and shell-scripting. Probably 
also in other scripts). Authenticating to the vault can be done on a session 
basis and shared. So locally, I'd only login once.

> > The root passwords are stored in a vault and I can get passwords out
> > using a script after authenticating.
> 
> Okay.
> 
> > Currently, I need to do a lot of the steps manually:
> > ssh @
> > su -
> 
> You could alter that slightly to be:
> 
> ssh @ su -
> 
> That would combine the steps into one.
> 
> > (copy/paste password from vault)
> 
> Are you actually copying & pasting the password?  Or will you be using
> something to retrieve the password from the vault and automatically
> provide it to su?

Currently, yes. I never physically see the password as it currently goes into 
the clipboard and gets wiped from there after a short time period. Enough time 
to paste it into the password-prompt. It's the copy/pasting that I am looking 
to automate into a single "login-to-remote-host" script.

> I think that removing the human's need ~> ability to copy & paste would
> close some security exposures.
> 
> Aside:  This remove the human's ability to copy ~> know the password
> from the mix as a security measure can be a slippery slope and I
> consider it to be questionable at best.  --  Conversely, doing it on
> behalf of the human with a password that they know simply as automation
> is fine.
> 
> > I would like to change this to:
> >  
> 
> I think that's doable.  I've done a lot of that.  I'll take it one step
> further and put " " in a for loop to do my bidding on
> a number of systems.
> 
> I think the "ssh @ su -" method might be a bit cleaner from
> a STDIN / TTY / FD perspective.
> 
> > Does anyone have any hints on how to achieve this without adding a
> > "NOPASSWD" entry into /etc/sudoers ?
> 
> Flag on the play:  You've now mixed privilege elevation mechanism.  You
> originally talked about "su" and now you're talking about "sudo".  They
> are distinctly different things.  Though admittedly they can be used in
> concert with each other.
> 
> If you are using SSH keys /and/ sudo, then I'd recommend that you
> investigate authenticating to sudo via (forwarded) SSH keys.  This means
> that your interactions with sudo are /always/ authenticated *and* done
> so without requiring an interactive prompt.

I prefer not to use SSH keys for this as they tend to exist for years in my 
experience. And one unnoticed leak can open up a lot of systems.
This is why I use passwords. (passwords are long random strings that are 
changed regularly)

> > Thanks in advance,
> 
> There's more than a little bit here.  There are a number of ways that
> this could go.

Re: [gentoo-user] Any way to automate login to host and su to root?

[J. Roeleveld]

On Thursday, 14 July 2022 17:32:07 CEST Grant Taylor wrote:
> On 7/14/22 3:54 AM, J. Roeleveld wrote:
> > For security reasons, I do not want direct login to root under any
> > circumstances. This is disabled on all systems and will stay this way.
> 
> +10 for security
> 
> > Currently, to login as root, you need to know:
> > - admin user account name
> > - admin user account password
> > - root user account password
> 
> Please describe what an ideal scenario would be from a flow perspective,
> independent of the underlying technology.

What I am looking for is:
1) Lookup credentials from password vault (I can do this in script-form, 
already doing this in limited form for ansible-scripts, but this doesn't give 
me an interactive shell)

2) Use admin-account credentials to login via SSH into host

3) On remote host, initiate "su -" to switch to root and provide root-password 
over SSH link at the right time

4) Give me an interactive root-shell on remote-host

When I close the shell, I expect to be fully logged out (eg, I go straight 
back to the local host, not to the admin-account)


> > I do not want to reduce this to a single ssh-key-passphrase.
> 
> Please elaborate as I suspect that the reasoning behind that statement
> is quite germane to this larger discussion.

I see plenty of google-results and also as answers for ssh directly to "root" 
using ssh-keys.  I do not consider this a safe method, I use it for un-
priviliges accounts (not member of "wheel"). I don't use it for admin-
accounts.