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
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.
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.
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,
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.
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.
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.
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...
Well, almost true.
Well, almost true.
Please elaborate.
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
I was accepting your point, one I hadn't considered.
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.
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)
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.
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.
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.
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.
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.
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 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.
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.
Indeed it is, and now you've found a way to do what you want with/me loudly says "SSH /certificates/" from the top atop a pile of old
passwords, all is well.
However, I will look at scripting regular replacements for SSH keys,
for my own peace of mind.
Have you looked at dev-tcltk/expect?
Yes.
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.
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 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)
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.
I'll check that out, but it is also possible to set time limits on SSH
keys, and limit them to specific commands.
However, I will look at scripting regular replacements for SSH keys,/me loudly says "SSH /certificates/" from the top atop a pile of old
for my own peace of mind.
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.
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.
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/.
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.
True, properly done automation is necessary to make our lives easier.
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.
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.
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)
True, but this needs to run from the client. Not the server. Which
means it will need to be triggered manually and not scheduled.
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.
It could, but that would open up an unsecured key to interception if
an intermediate host is compromised.
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.
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.
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.
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 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.
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.
When hosts can get added and removed regularly for testing purposes,
this requires a management tool.
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 expect the "wheel" group to only be for changing into "root",
that's what it's advertised as.
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 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.
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.
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.
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.
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.
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.
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.
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
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 302 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 96:51:09 |
| Calls: | 6,764 |
| Calls today: | 2 |
| Files: | 12,295 |
| Messages: | 5,376,370 |
| Posted today: | 1 |