Mailing List Archive

Any way to automate login to host and su to root?
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 <user>@<host>
su -
(copy/paste password from vault)

I would like to change this to:
<some-script> <host>

Does anyone have any hints on how to achieve this without adding a "NOPASSWD"
entry into /etc/sudoers ?

Thanks in advance,

Joost
Re: Any way to automate login to host and su to root? [ In reply to ]
Le jeu. 14 juil. 2022 à 08:35, J. Roeleveld <joost@antarean.org> a écrit :
>
> 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 <user>@<host>
> su -
> (copy/paste password from vault)

Why not use directly ssh root@<host> ?
With an SSH key protected by a passphrase that would be a single step
to connect.
You would have a passphrase to manage but you already are using a tool for that.
If you accept the risks, you could also use an SSH key without a passphrase.

sshd on the host must be configured with
PermitRootLogin=prohibit-password at minimum, which is the default
value.

> I would like to change this to:
> <some-script> <host>
>
> Does anyone have any hints on how to achieve this without adding a "NOPASSWD"
> entry into /etc/sudoers ?
>
> Thanks in advance,
>
> Joost

Best regards

Mickaël Bucas
Re: Any way to automate login to host and su to root? [ In reply to ]
On Thursday, 14 July 2022 10:04:21 CEST Micka?l Bucas wrote:
> Le jeu. 14 juil. 2022 ? 08:35, J. Roeleveld <joost@antarean.org> a ?crit :
> > 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 <user>@<host>
> > su -
> > (copy/paste password from vault)
>
> Why not use directly ssh root@<host> ?
> With an SSH key protected by a passphrase that would be a single step
> to connect.
> You would have a passphrase to manage but you already are using a tool for
> that. If you accept the risks, you could also use an SSH key without a
> passphrase.
>
> sshd on the host must be configured with
> PermitRootLogin=prohibit-password at minimum, which is the default
> value.

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.

Currently, to login as root, you need to know:
- admin user account name
- admin user account password
- root user account password

I do not want to reduce this to a single ssh-key-passphrase.

--
Joost
Re: Any way to automate login to host and su to root? [ In reply to ]
On Thu, 14 Jul 2022 11:54:46 +0200, 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.
>
> Currently, to login as root, you need to know:
> - admin user account name
> - admin user account password
> - root user account password
>
> I do not want to reduce this to a single ssh-key-passphrase.

Is this user only used as a gateway to root access, or can you set up such
a user? If so you could use key-based authentication for that user, with
a passphrase, and add command="/bin/su --login" to the authorized_keys
line. That way you still need three pieces of information, replacing the
user's password with the user's key passphrase.


--
Neil Bothwick

30 minutes of begging is not considered foreplay.
Re: Any way to automate login to host and su to root? [ In reply to ]
Em qui., 14 de jul. de 2022 11:48, Neil Bothwick <neil@digimed.co.uk>
escreveu:

> On Thu, 14 Jul 2022 11:54:46 +0200, 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.
> >
> > Currently, to login as root, you need to know:
> > - admin user account name
> > - admin user account password
> > - root user account password
> >
> > I do not want to reduce this to a single ssh-key-passphrase.
>
> Is this user only used as a gateway to root access, or can you set up such
> a user? If so you could use key-based authentication for that user, with
> a passphrase, and add command="/bin/su --login" to the authorized_keys
> line. That way you still need three pieces of information, replacing the
> user's password with the user's key passphrase.
>
>
> --
> Neil Bothwick
>
> 30 minutes of begging is not considered foreplay.
>

Or you might consider creating a ssh key pair for the remote root and login
directly to root with no password, only using the ssh keys.

>
Re: Any way to automate login to host and su to root? [ In reply to ]
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?

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.

> 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 <user>@<host>
> su -

You could alter that slightly to be:

ssh <user>@<host> 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?

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:
> <some-script> <host>

I think that's doable. I've done a lot of that. I'll take it one step
further and put "<some-script> <host>" in a for loop to do my bidding on
a number of systems.

I think the "ssh <user>@<host> 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.

> Thanks in advance,

There's more than a little bit here. There are a number of ways that
this could go.



--
Grant. . . .
unix || die
Re: Any way to automate login to host and su to root? [ In reply to ]
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.

> 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.



--
Grant. . . .
unix || die
Re: Any way to automate login to host and su to root? [ In reply to ]
On 7/14/22 8:48 AM, Neil Bothwick wrote:
> Is this user only used as a gateway to root access, or can you set
> up such a user? If so you could use key-based authentication for
> that user, with a passphrase, and add command="/bin/su --login"
> to the authorized_keys line. That way you still need three pieces
> of information,

Be mindful that despite the fact that this protects things on the
surface, it is / can be a way to boot strap changing this.

After all, nothing about this forced command prevents the user from
using the acquired root access to modify the ~/.ssh/authorized_keys file
enforcing the command.

This is one of the pitfalls that I alluded to in my earlier reply about
security vs automation. Quite simply, this is NOT security as it's
trivial to use the access (su -) to gain more access (edit the
~/.ssh/authorized_keys file).

> replacing the user's password with the user's key passphrase.

This is another slippery slope. SSH key pass phrases can be brute
forced in an offline fashion. Conversely, system passwords are more of
an online attack. Assuming that standard system protections are in
place for /etc/shadow*. -- It's easier to get a copy of someone's
private SSH key file, especially if they are somewhat lax about it's
security believing that the passphrase will protect it.



--
Grant. . . .
unix || die
Re: Any way to automate login to host and su to root? [ In reply to ]
On Thu, 14 Jul 2022 09:37:45 -0600, Grant Taylor wrote:

> > Is this user only used as a gateway to root access, or can you set
> > up such a user? If so you could use key-based authentication for
> > that user, with a passphrase, and add command="/bin/su --login"
> > to the authorized_keys line. That way you still need three pieces
> > of information,
>
> Be mindful that despite the fact that this protects things on the
> surface, it is / can be a way to boot strap changing this.
>
> After all, nothing about this forced command prevents the user from
> using the acquired root access to modify the ~/.ssh/authorized_keys
> file enforcing the command.

That is true, but it is also true about the current setup as that also
gives root access. I get the impression that Joost is looking for a more
convenient approach that does not reduce security, which is true here...

> > replacing the user's password with the user's key passphrase.
>
> This is another slippery slope. SSH key pass phrases can be brute
> forced in an offline fashion. Conversely, system passwords are more of
> an online attack.

Well, almost true.


--
Neil Bothwick

Barth's Distinction:
There are two types of people: those who divide people into two types, and
those who don't.
Re: Any way to automate login to host and su to root? [ In reply to ]
On 7/14/22 9:56 AM, Neil Bothwick wrote:
> That is true, but it is also true about the current setup as that
> also gives root access. I get the impression that Joost is looking
> for a more convenient approach that does not reduce security, which
> is true here...

I'm all for being /more/ secure, especially when doing so can be made to
appear to be /simpler/ for the end user.

I think the quintessential example of this is authenticating to sudo
with SSH keys via SSH agent forwarding. It eliminates the password
prompt or the NOPASSWD: option. Either way, you have better security
posture (always authenticated) and / or users have a better experience
(no password prompt).

> Well, almost true.

Please elaborate.

I consider it fairly difficult for non-root users to get a copy of the
/etc/shadow file on most systems. Conversely, SSH private key files
tend to ... leak / be forgotten.



--
Grant. . . .
unix || die
Re: Any way to automate login to host and su to root? [ In reply to ]
On Thu, 14 Jul 2022 11:01:29 -0600, Grant Taylor wrote:

> > Well, almost true.
>
> Please elaborate.

I was accepting your point, one I hadn't considered.


--
Neil Bothwick

. <-Stealth Tagline
Re: Any way to automate login to host and su to root? [ In reply to ]
Have you looked at dev-tcltk/expect?

There's possibly an example you could try at
<https://www.journaldev.com/1405/expect-script-ssh-example-tutorial>
although you probably want to prompt for the password or retreive it
programatically rather than putting it on the command line :o

Steve.

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 <user>@<host>
> su -
> (copy/paste password from vault)
>
> I would like to change this to:
> <some-script> <host>
>
> Does anyone have any hints on how to achieve this without adding a "NOPASSWD"
> entry into /etc/sudoers ?
>
> Thanks in advance,
>
> Joost
>
>
>
Re: Any way to automate login to host and su to root? [ In reply to ]
On 7/14/22 1:08 PM, Neil Bothwick wrote:
> I was accepting your point, one I hadn't considered.

Ah. Okay. :-/ Here I was hoping to learn something new from you. ;-)
Still a good discussion none the less. :-)



--
Grant. . . .
unix || die
Re: Any way to automate login to host and su to root? [ In reply to ]
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.
Re: Any way to automate login to host and su to root? [ In reply to ]
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 <user>@<host>
> > su -
>
> You could alter that slightly to be:
>
> ssh <user>@<host> 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:
> > <some-script> <host>
>
> I think that's doable. I've done a lot of that. I'll take it one step
> further and put "<some-script> <host>" in a for loop to do my bidding on
> a number of systems.
>
> I think the "ssh <user>@<host> 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: Any way to automate login to host and su to root? [ In reply to ]
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.
Re: Any way to automate login to host and su to root? [ In reply to ]
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: Any way to automate login to host and su to root? [ In reply to ]
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 <user>@<host>
> > su -
> > (copy/paste password from vault)
> >
> > I would like to change this to:
> > <some-script> <host>
> >
> > 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
> <https://www.journaldev.com/1405/expect-script-ssh-example-tutorial>
> 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: Any way to automate login to host and su to root? [ In reply to ]
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 <user>@<host>
> > > su -
> > > (copy/paste password from vault)
> > >
> > > I would like to change this to:
> > > <some-script> <host>
> > >
> > > 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
> > <https://www.journaldev.com/1405/expect-script-ssh-example-tutorial>
> > 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: Any way to automate login to host and su to root? [ In reply to ]
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."
Re: Any way to automate login to host and su to root? [ In reply to ]
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 <remote_user>@<remote_host> "/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: Any way to automate login to host and su to root? [ In reply to ]
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: Any way to automate login to host and su to root? [ In reply to ]
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: Any way to automate login to host and su to root? [ In reply to ]
On 7/15/22 6:44 AM, Neil Bothwick wrote:
> I don't share keys, each desktop/laptop has its own keys.

<ASCII thumbs up>

> 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: Any way to automate login to host and su to root? [ In reply to ]
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: Any way to automate login to host and su to root? [ In reply to ]
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?
Re: Any way to automate login to host and su to root? [ In reply to ]
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
Re: Any way to automate login to host and su to root? [ In reply to ]
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)
Re: Any way to automate login to host and su to root? [ In reply to ]
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: Any way to automate login to host and su to root? [ In reply to ]
On Friday, 15 July 2022 14:44:10 CEST Neil Bothwick wrote:
> 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.

I agree this is more secure as you can remove potentially leaked keys
individually. But with more devices, the amount of keys and places where these
need to be removed increases.

> > 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.

This script will need to be run by the individual user. I prefer to control
this centrally.

> > 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.

Most security improvements start with "simple" questions like these :)

Good luck with your scripts :)

--
Joost
Re: Any way to automate login to host and su to root? [ In reply to ]
On Friday, 15 July 2022 18:32:52 CEST Grant Taylor wrote:
> 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.

True, properly done automation is necessary to make our lives easier.

> > 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 tried this approach in the past and some levels of automation still use
this, but for being able to login myself, I found having different keys become
cumbersome and I ended up never actually replacing them.

> > I assume the same is true for most people.
>
> Yes. It depends what security posture you / your organization want.

The goal is to have whichever authentication system used, the passwords/keys
to be replaced often with hard to brute-force passwords/keys. I can currently
replace all passwords on a daily basis and not have a problem with accessing
any system.

> > 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.

For normal use, most systems don't need to be logged into a shell. For the few
where this is needed, individual accounts exists.
But, no individual account is a member of "wheel".
For admin access, there are admin accounts on the machines. (they are all
named individually and you won't find the same admin-account-username on more
then 1 system)

> > 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.

True, but this needs to run from the client. Not the server. Which means it
will need to be triggered manually and not scheduled.

> 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:.

I don't even have sudo installed on most systems, only where it's needed for
certain scripts to work and there it's only used to avoid "setuid" which is an
even bigger issue.

--
Joost
Re: Any way to automate login to host and su to root? [ In reply to ]
On Friday, 15 July 2022 18:15:04 CEST Grant Taylor wrote:
> 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.

Hmm... interesting. I will look into this.
But, it needs the agent to be running, which will make it tricky for
automation. (I have some scripts that need to do things on different systems
in a sequence for which this could help)

> > 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 know, which is why I was investigating automating it. The passwords are too
long to comfortably copy by hand.

> 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.

I will definitely investigate this. They sound interesting. I'd set the
validity to a lot less if this can be automated easily.

> 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.

Added to my research-list.

--
Joost
Re: Any way to automate login to host and su to root? [ In reply to ]
On Fri, 15 Jul 2022 22:33:49 -0600, Grant Taylor 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/.

valid-before/valid-after are documented elsewhere in the man page, but it
is not clear whether they are discussing certificates or keys at that
point, it could be read either way.

Time to check out certificates.


--
Neil Bothwick

Set phasers to extreme itching!
Re: Any way to automate login to host and su to root? [ In reply to ]
On 7/15/22 11:42 PM, J. Roeleveld wrote:
> True, properly done automation is necessary to make our lives easier.

#truth

> I tried this approach in the past and some levels of automation still
> use this, but for being able to login myself, I found having different
> keys become cumbersome and I ended up never actually replacing them.

I'm curious what you found to be cumbersome.

I make extensive use of the client SSH configuration file
(~/.ssh/config) such that I don't need to worry about which key is used
for which host. This means that anything that uses ssh / sftp / scp
/just/ /works/ (tm) using the contents of the configuration file.

> The goal is to have whichever authentication system used, the
> passwords/keys to be replaced often with hard to brute-force
> passwords/keys. I can currently replace all passwords on a daily
> basis and not have a problem with accessing any system.

I agree in concept. Though I question the veracity of that statement
when things aren't working normally. E.g. system is offline for X hours
do to hardware failure or an old version restored from backup that is
now out of sync with the central system.

> For normal use, most systems don't need to be logged into a shell. For
> the few where this is needed, individual accounts exists. But, no
> individual account is a member of "wheel". For admin access, there are
> admin accounts on the machines. (they are all named individually and
> you won't find the same admin-account-username on more then 1 system)

I've wondered about having the account for UID / GID 0 be named
something other than root. But the testing that I did showed that there
were too many things that assumed "root". :-/

Though I did find that I was able to successfully convert a test VM to
use something other than root and the proof of concept was a success.
It's just that the PoC was too much effort / fragile to be used in
production.

I find that the wheel group is mostly for su and a few other commands.
But the concept of you must be a member of a group or have special
permissions applied directly to your account is conceptually quite
similar to being a member of the wheel group. As such I don't think the
abstraction makes much difference other than obfuscation.

> True, but this needs to run from the client. Not the server. Which
> means it will need to be triggered manually and not scheduled.

The algorithm could be refactored such that it is run from the server.
E.g. if you can ensure that the old key is replaced with the new key, it
can safely be done server side. I did this for a few colleagues that
had forgotten the passphrase for their old private key and needed their
new public key to be put into place.

> I don't even have sudo installed on most systems, only where it's
> needed for certain scripts to work and there it's only used to avoid
> "setuid" which is an even bigger issue.

I tend to prefer sudo's security posture where people need to know
/their/ password. Meaning that there was no need for multiple people to
know the shared target user's password like su does.

If I was in a different environment, I'd consider Kerberized versions of
su as an alternative.



--
Grant. . . .
unix || die
Re: Any way to automate login to host and su to root? [ In reply to ]
On 7/15/22 11:46 PM, J. Roeleveld wrote:
> Hmm... interesting. I will look into this.

:-)

> But, it needs the agent to be running, which will make it tricky for
> automation.

Why can't automation start an agent? Why can't there be an agent
running that automation has access to?

> (I have some scripts that need to do things on different systems in
> a sequence for which this could help)

:-)

> I know, which is why I was investigating automating it. The passwords
> are too long to comfortably copy by hand.

I assume that you mean "type" when you say "copy".

> I will definitely investigate this. They sound interesting. I'd set
> the validity to a lot less if this can be automated easily.

Yes, it can be fairly easily automated.

One of the other advantages of SSH /certificates/ is when you flip
things around and use a /host/ certificate. Clients can recognize that
the target host's certificate is signed by the trusted SSH CA and not
prompt for the typical Trust On First Use (TOFU) scenario. Thus you can
actually leverage the target host SSH fingerprint and not need to ignore
that security aspect like so many people do.

> Added to my research-list.

:-)



--
Grant. . . .
unix || die
Re: Any way to automate login to host and su to root? [ In reply to ]
On Sunday, 17 July 2022 21:10:52 CEST Grant Taylor wrote:
> On 7/15/22 11:42 PM, J. Roeleveld wrote:
> > True, properly done automation is necessary to make our lives easier.
>
> #truth
>
> > I tried this approach in the past and some levels of automation still
> > use this, but for being able to login myself, I found having different
> > keys become cumbersome and I ended up never actually replacing them.
>
> I'm curious what you found to be cumbersome.

If I have 1 desktop and 1 laptop, that means 2 client machines.
Add 5 servers/vms.
That means 10 ssh-keys per person to manage and keep track off.
When a laptop gets replaced, I need to ensure the keys get removed from the
authorized_keys section. Same goes for when the ssh-keys need refreshing.
Which, due to the amount, I never got round to.

I actually have more then the amount mentioned above, the amount of ssh-keys
gets too much to manage without an automated tool to keep track of them and
automate the changing of the keys. I never got the time to create that tool
and never found anything that would make it easier.

> I make extensive use of the client SSH configuration file
> (~/.ssh/config) such that I don't need to worry about which key is used
> for which host. This means that anything that uses ssh / sftp / scp
> /just/ /works/ (tm) using the contents of the configuration file.

When hosts can get added and removed regularly for testing purposes, this
requires a management tool.

> > The goal is to have whichever authentication system used, the
> > passwords/keys to be replaced often with hard to brute-force
> > passwords/keys. I can currently replace all passwords on a daily
> > basis and not have a problem with accessing any system.
>
> I agree in concept. Though I question the veracity of that statement
> when things aren't working normally. E.g. system is offline for X hours
> do to hardware failure or an old version restored from backup that is
> now out of sync with the central system.

Down due to hardware issues means the password-refresh fails for this host.
Backup-restore scripts have a step added to update the passwords updated to
whatever is in the vault before the system is brought back online.

I actually considered these and made sure it can handle this. The most common
issue is a network link being down due to ISP issues.

> > For normal use, most systems don't need to be logged into a shell. For
> > the few where this is needed, individual accounts exists. But, no
> > individual account is a member of "wheel". For admin access, there are
> > admin accounts on the machines. (they are all named individually and
> > you won't find the same admin-account-username on more then 1 system)
>
> I've wondered about having the account for UID / GID 0 be named
> something other than root. But the testing that I did showed that there
> were too many things that assumed "root". :-/

You could put "root" without a valid password, making it impossible to "su -"
into and add a 2nd uid/gid 0 account with a valid password. I know of 1
organisation where they had a 2nd root account added which could be used by
the orgs sys-admins for emergency access. (These were student owned servers
directly connected to the internet)

> Though I did find that I was able to successfully convert a test VM to
> use something other than root and the proof of concept was a success.
> It's just that the PoC was too much effort / fragile to be used in
> production.
>
> I find that the wheel group is mostly for su and a few other commands.
> But the concept of you must be a member of a group or have special
> permissions applied directly to your account is conceptually quite
> similar to being a member of the wheel group. As such I don't think the
> abstraction makes much difference other than obfuscation.

I expect the "wheel" group to only be for changing into "root", that's what
it's advertised as.

> > True, but this needs to run from the client. Not the server. Which
> > means it will need to be triggered manually and not scheduled.
>
> The algorithm could be refactored such that it is run from the server.
> E.g. if you can ensure that the old key is replaced with the new key, it
> can safely be done server side. I did this for a few colleagues that
> had forgotten the passphrase for their old private key and needed their
> new public key to be put into place.

Still needs the clients to be actually running when the server runs the
script. Or it needs to be added to a schedule and gets triggered when the
client becomes available. This would make the scheduler too complex.

> > I don't even have sudo installed on most systems, only where it's
> > needed for certain scripts to work and there it's only used to avoid
> > "setuid" which is an even bigger issue.
>
> I tend to prefer sudo's security posture where people need to know
> /their/ password. Meaning that there was no need for multiple people to
> know the shared target user's password like su does.

I agree, but root-access is only needed for specific tasks, like updates.
Most access is done using service-specific accounts. I only have 2 where users
have shell-accounts.

> If I was in a different environment, I'd consider Kerberized versions of
> su as an alternative.

I'd love to implement Kerberos, mostly for the SSO abilities, but haven't
found a simple to follow howto yet which can be easily adjusted so it can be
added to an existing environment.

--
Joost
Re: Any way to automate login to host and su to root? [ In reply to ]
On Sunday, 17 July 2022 21:15:05 CEST Grant Taylor wrote:
> On 7/15/22 11:46 PM, J. Roeleveld wrote:
> > Hmm... interesting. I will look into this.
> :
> :-)
> :
> > But, it needs the agent to be running, which will make it tricky for
> > automation.
>
> Why can't automation start an agent?

It could, but that would open up an unsecured key to interception if an
intermediate host is compromised.

> Why can't there be an agent
> running that automation has access to?

See previous answer, the agent, as far as I know, will have the keys in memory
and I haven't seen evidence that it won't provide the keys without
authenticating the requestor.

> > I know, which is why I was investigating automating it. The passwords
> > are too long to comfortably copy by hand.
>
> I assume that you mean "type" when you say "copy".

Yes, copy/paste has no issues with multi-page texts. But manually reading a
long password and copying that over by typing on a keyboard when the font can
make the difference between "1" (ONE), "l" (small letter L) and "|" (pipe-
character) and similar characters make it annoying to say the least.

> > I will definitely investigate this. They sound interesting. I'd set
> > the validity to a lot less if this can be automated easily.
>
> Yes, it can be fairly easily automated.
>
> One of the other advantages of SSH /certificates/ is when you flip
> things around and use a /host/ certificate. Clients can recognize that
> the target host's certificate is signed by the trusted SSH CA and not
> prompt for the typical Trust On First Use (TOFU) scenario. Thus you can
> actually leverage the target host SSH fingerprint and not need to ignore
> that security aspect like so many people do.

Currently, when that comment pops up, the first thing I do is wait and wonder
why it's asking for it. As all the systems are already added to the list.

--
Joost
Re: Any way to automate login to host and su to root? [ In reply to ]
On 7/17/22 11:24 PM, J. Roeleveld wrote:
> If I have 1 desktop and 1 laptop, that means 2 client machines.
> Add 5 servers/vms.

/Clients/ need (non-host) key pairs. Servers shouldn't need non-host
key pairs. Servers should only need the clients' public keys on them.

> That means 10 ssh-keys per person to manage and keep track off.

If you're using per-host-per-client key pairs, sure. If you're only
using per-client key pairs and copying the public key to the server, no.

> When a laptop gets replaced, I need to ensure the keys get removed
> from the authorized_keys section.

If the new key pair would be using the same algorithm and bit length and
there is no reason to suspect compromise, then I see no reason to
replace the key pair. I'd just copy the key pair from the old client to
the new client and destroy it on the old client. This is especially
true if the authorized_keys file has a from stanza on the public key.

> Same goes for when the ssh-keys need refreshing. Which, due to the
> amount, I never got round to.

I've not run into any situation where policy mandates that a key pair be
replaced unless when there isn't any reason to suspect it's compromise.

> I actually have more then the amount mentioned above, the amount of
> ssh-keys gets too much to manage without an automated tool to keep
> track of them and automate the changing of the keys. I never got the
> time to create that tool and never found anything that would make
> it easier.

As I think about it, I'd probably leverage the comment stanza of the
public key so that I could do an in place delete with sed and then
append the new public key. E.g. have a comment that consists of the
client's host name, some delimiter, and the date. That way it would be
easy to remove any and all keys for the client in the future.

> When hosts can get added and removed regularly for testing purposes,
> this requires a management tool.

It depends on how you configure things.

It seems as if it's possible to use the "%h" parameter when specifying
the IdentityFile. So you could have a wild card stanza that would look
for a file based on the host name.

> You could put "root" without a valid password, making it impossible to
> "su -" into and add a 2nd uid/gid 0 account with a valid password. I
> know of 1 organisation where they had a 2nd root account added which
> could be used by the orgs sys-admins for emergency access. (These
> were student owned servers directly connected to the internet)

I absolutely hate the idea of having multiple accounts using the same
UID. I'd be far more likely to have a per host account with UID=0 /
GID=0 and have the root account have a different UID / GID.

I'll need to try this at some point in the future.

> I expect the "wheel" group to only be for changing into "root",
> that's what it's advertised as.

I've seen some binaries in the wheel group and 0550 permission.

> Still needs the clients to be actually running when the server runs
> the script. Or it needs to be added to a schedule and gets triggered
> when the client becomes available. This would make the scheduler
> too complex.

Why can't the script that's running ssh simply start an agent, run ssh,
then stop the agent? There's no coordination necessary.

> I agree, but root-access is only needed for specific tasks, like
> updates. Most access is done using service-specific accounts. I only
> have 2 where users have shell-accounts.

Many people forget about problems on boot that require root's password.

> I'd love to implement Kerberos, mostly for the SSO abilities,
> but haven't found a simple to follow howto yet which can be easily
> adjusted so it can be added to an existing environment.

ACK



--
Grant. . . .
unix || die
Re: Any way to automate login to host and su to root? [ In reply to ]
On 7/17/22 11:48 PM, J. Roeleveld wrote:
> It could, but that would open up an unsecured key to interception if
> an intermediate host is compromised.

What are you thinking? -- I've got a few ideas, but rather than
speculating, I'll just ask.

> See previous answer, the agent, as far as I know, will have the keys
> in memory and I haven't seen evidence that it won't provide the keys
> without authenticating the requestor.

Are you concerned about a rogue requestor on the host where the agent is
running or elsewhere?

> Yes, copy/paste has no issues with multi-page texts. But manually
> reading a long password and copying that over by typing on a keyboard
> when the font can make the difference between "1" (ONE), "l" (small
> letter L) and "|" (pipe- character) and similar characters make it
> annoying to say the least.

Agreed.

> Currently, when that comment pops up, the first thing I do is wait
> and wonder why it's asking for it. As all the systems are already
> added to the list.

Such a pop-up would be a very likely indication of a problem.



--
Grant. . . .
unix || die
Re: Any way to automate login to host and su to root? [ In reply to ]
On Friday, 15 July 2022 18:39:25 CEST Grant Taylor wrote:
> 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.

I agree

> 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.

I've been using ansible for some of my automation scripts and am happy with
the way that works. The existing implementations for "adding users" and such
is tested plenty by others and does actually check if the user exists before
trying to add one.

> 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.

I only use expect to automate the login-process as mentioned in the original
email. The line it's expecting is more then just "*?assword" like in all the
examples.

Currently, SSH puts the password-prompt as:
(<username>@<hostname>) Password:

As I know both, the expected string is this full line. If SSH changes its
behaviour, the script will simply fail.

--
Joost
Re: Any way to automate login to host and su to root? [ In reply to ]
On Monday, 18 July 2022 08:03:44 CEST Grant Taylor wrote:
> On 7/17/22 11:48 PM, J. Roeleveld wrote:
> > It could, but that would open up an unsecured key to interception if
> > an intermediate host is compromised.
>
> What are you thinking? -- I've got a few ideas, but rather than
> speculating, I'll just ask.

See below

> > See previous answer, the agent, as far as I know, will have the keys
> > in memory and I haven't seen evidence that it won't provide the keys
> > without authenticating the requestor.
>
> Are you concerned about a rogue requestor on the host where the agent is
> running or elsewhere?

Either on the client where the agent is running, but also on the system I connected to.
But, I just noticed the following, which is hopeful, but need to read up on this:
https://www.openssh.com/agent-restrict.html[1]

> > Yes, copy/paste has no issues with multi-page texts. But manually
> > reading a long password and copying that over by typing on a keyboard
> > when the font can make the difference between "1" (ONE), "l" (small
> > letter L) and "|" (pipe- character) and similar characters make it
> > annoying to say the least.
>
> Agreed.
>
> > Currently, when that comment pops up, the first thing I do is wait
> > and wonder why it's asking for it. As all the systems are already
> > added to the list.
>
> Such a pop-up would be a very likely indication of a problem.

Agreed, which is why I always stop and think when I see that.
Usually the answer is: "Oh, yes, I didn't access this host from my laptop yet". But that is usually
after the 2nd or 3rd connection attempt with retyping the hostname and verifying the IP-address
that is resolved for it first.

--
Joost

--------
[1] https://www.openssh.com/agent-restrict.html
Re: Any way to automate login to host and su to root? [ In reply to ]
On 7/18/22 12:23 AM, J. Roeleveld wrote:
> I've been using ansible for some of my automation scripts and am
> happy with the way that works. The existing implementations for
> "adding users" and such is tested plenty by others and does actually
> check if the user exists before trying to add one.

ACK

> I only use expect to automate the login-process as mentioned in the
> original email.

I've been a fan of the sshpass command explicitly for sshing into
systems. Though I've gotten it to work for a few other very similar things.

> The line it's expecting is more then just "*?assword" like in all
> the examples.
>
> Currently, SSH puts the password-prompt as:
> (<username>@<hostname>) Password:
>
> As I know both, the expected string is this full line. If SSH changes
> its behaviour, the script will simply fail.

Nice!



--
Grant. . . .
unix || die
Re: Any way to automate login to host and su to root? [ In reply to ]
On 7/18/22 3:28 AM, J. Roeleveld wrote:
> Either on the client where the agent is running, but also on the
> system I connected to.

I have always considered that there is enough sensitive data on the
client and that there are already enough things running there that I end
up considering the client a sensitive / secure system as a unit. This
seems to be especially true with servers hosting automation. But to
each their own.

As for the security of the forwarded agent, I've generally been okay
with root on the target system having access to the agent. Especial
when I have used different key pairs for different destination hosts and
/ or specify the from stanza in the authorized_keys file.

If you want to, you can specify how long, in seconds, that a key can be
used in an agent. So if you have a running agent, you can load a key
and specify that it can be used for up to two seconds. So even if
someone does compromise the target host and does talk to the agent, the
agent won't allow the key to be used and will behave as if the key
wasn't loaded.

You can also lock / unlock the agent on the source side as you see fit.
Unlock it for authentication, and then immediately re-lock it after
authenticating. Local commands and / or a local process using ssh
remote commands makes this more reasonable.

Aside: Backgrounded / multiplexed connections make running multiple
remote commands on a host a lot more expedient.

1) Log in to the remote host with a background connection.
2) Run multiple remote commands via "ssh <username>@<hostname>
<command>"
3) Log out of the remote host closing the background connection.

The business logic of the script lives on the client and all the
intermediate commands (#2) avoid the overhead of establishing a
connection and authenticating again.

> But, I just noticed the following, which is hopeful, but need to read
> up on this:
>
> https://www.openssh.com/agent-restrict.html

Interesting. More reading.

> Agreed, which is why I always stop and think when I see that.

;-)

> Usually the answer is: "Oh, yes, I didn't access this host from my
> laptop yet". But that is usually after the 2nd or 3rd connection
> attempt with retyping the hostname and verifying the IP-address that
> is resolved for it first.

I think I mis-took a previous statement to mean that you did something
to distribute the contents of the known_hosts file so that re-loads
would already be known. I guess I misunderstood.



--
Grant. . . .
unix || die