sudo problems

scottalanmiller

@scottalanmiller said in sudo problems:

The sudo mechanism is used to make privileged accounts safer. That's all. That's all that it can do, because any account with access to it is, by definition, already a privileged account. The privilege is the access to sudo. Sudo is a great tool that we use all the time because it truly makes privileged accounts dramatically safer than they were before. But it's one of those super dangerous things to start thinking that an account with sudo rights isn't privileged already, because it is.

Yeah, I like that. I think I've confused myself on what sudo actually does.

It's a great mechanism, don't get me wrong. I highly recommend it for most cases.

scottalanmiller

@pete-s said in sudo problems:

Facebook uses shared accounts with ssh certificates.

Actually quite common.

JaredBusch

@scottalanmiller said in sudo problems:

@pete-s said in sudo problems:

We want to move to using ssh certificates on our servers and remove all passwords.

That's what we do.

Since when? What do you use to manage and generate certificates?

EddieJennings

@scottalanmiller said in sudo problems:

I can prove the degree to which sudo exposes that it is allowing a privileged account to take an action compared to allowing access to a privileged account (which can be argued is the same thing, both are privileges, but sudo is more extreme of the original account being the privileged one.) Older tools, like su allow the user to move from using their own unprivileged account to using root (or something else) that is privileged. Sudo does not, sudo still acts as the original account which has been given admin level rights.

Here is how you can see it in action...
scott@ntg-scott-lnx-desk:/tmp$ sudo touch test1
scott@ntg-scott-lnx-desk:/tmp$ ll | grep test
-rw-rw-r--  1 scott scott     0 Jul 19 15:34 test0
-rw-rw-r--  1 scott scott     0 Jul 19 15:34 test1
Notice that when I made a file using sudo, it didn't make the file as root or any other account, the action was taken by the same account. Just in one case access to privileges was allowed and in the other case it was protected. But the account itself has the privileges in this case, just administered by the sudo mechanism.

A little test on my Fedora 34

JaredBusch

@eddiejennings said in sudo problems:

A little test on my Fedora 34

Did you disable the password requirement for sudo? Because by default that is required.

EddieJennings

@jaredbusch said in sudo problems:

@eddiejennings said in sudo problems:

A little test on my Fedora 34

Did you disable the password requirement for sudo? Because by default that is required.

I did for the wheel group. Below are the results. This thread interests me because I've always seen processes ran using sudo or files made using sudo are run as / owned by root. I was looking through /etc/sudo.conf and no setting seemed like it would change this behavior.

scottalanmiller

@jaredbusch said in sudo problems:

@scottalanmiller said in sudo problems:

@pete-s said in sudo problems:

We want to move to using ssh certificates on our servers and remove all passwords.

That's what we do.

Since when? What do you use to manage and generate certificates?

Generate with ssh-keygen. Manage with a wiki. We are only so big, so it works fine.

scottalanmiller

@eddiejennings said in sudo problems:

@scottalanmiller said in sudo problems:
I can prove the degree to which sudo exposes that it is allowing a privileged account to take an action compared to allowing access to a privileged account (which can be argued is the same thing, both are privileges, but sudo is more extreme of the original account being the privileged one.) Older tools, like su allow the user to move from using their own unprivileged account to using root (or something else) that is privileged. Sudo does not, sudo still acts as the original account which has been given admin level rights.

Here is how you can see it in action...
scott@ntg-scott-lnx-desk:/tmp$ sudo touch test1
scott@ntg-scott-lnx-desk:/tmp$ ll | grep test
-rw-rw-r--  1 scott scott     0 Jul 19 15:34 test0
-rw-rw-r--  1 scott scott     0 Jul 19 15:34 test1
Notice that when I made a file using sudo, it didn't make the file as root or any other account, the action was taken by the same account. Just in one case access to privileges was allowed and in the other case it was protected. But the account itself has the privileges in this case, just administered by the sudo mechanism.
A little test on my Fedora 34

That's weird. Why is it one way on Ubuntu and one way on Fedora?

scottalanmiller

@eddiejennings said in sudo problems:

@jaredbusch said in sudo problems:

@eddiejennings said in sudo problems:

A little test on my Fedora 34

Did you disable the password requirement for sudo? Because by default that is required.

I did for the wheel group. Below are the results. This thread interests me because I've always seen processes ran using sudo or files made using sudo are run as / owned by root. I was looking through /etc/sudo.conf and no setting seemed like it would change this behavior.

Yeah, I use that setting most of the time, too.

JaredBusch

@scottalanmiller said in sudo problems:

@jaredbusch said in sudo problems:

@scottalanmiller said in sudo problems:

@pete-s said in sudo problems:

We want to move to using ssh certificates on our servers and remove all passwords.

That's what we do.

Since when? What do you use to manage and generate certificates?

Generate with ssh-keygen. Manage with a wiki. We are only so big, so it works fine.

That is not certificates. That is keys. Completely different.

1337

@jaredbusch said in sudo problems:

@scottalanmiller said in sudo problems:

@jaredbusch said in sudo problems:

@scottalanmiller said in sudo problems:

@pete-s said in sudo problems:

We want to move to using ssh certificates on our servers and remove all passwords.

That's what we do.

Since when? What do you use to manage and generate certificates?

Generate with ssh-keygen. Manage with a wiki. We are only so big, so it works fine.

That is not certificates. That is keys. Completely different.

I don't know what @scottalanmiller uses but ssh-keygen is used to generate ssh certificates as well.

From the man page:
ssh-keygen supports signing of keys to produce certificates that may be used for user or host authentication. Certificates consist of a public key, some identity information, zero or more principal (user or host) names and a set of options that are signed by a Certification Authority (CA) key. Clients or servers may then trust only the CA key and verify its signature on a certificate rather than trusting many user/host keys. Note that OpenSSH certificates are a different, and much simpler, format to the X.509 certificates used in ssl(8).

But if you are automating certificate generation, you need to wrap this in something.

EddieJennings

@scottalanmiller said in sudo problems:

@eddiejennings said in sudo problems:
@scottalanmiller said in sudo problems:
I can prove the degree to which sudo exposes that it is allowing a privileged account to take an action compared to allowing access to a privileged account (which can be argued is the same thing, both are privileges, but sudo is more extreme of the original account being the privileged one.) Older tools, like su allow the user to move from using their own unprivileged account to using root (or something else) that is privileged. Sudo does not, sudo still acts as the original account which has been given admin level rights.

Here is how you can see it in action...
scott@ntg-scott-lnx-desk:/tmp$ sudo touch test1
scott@ntg-scott-lnx-desk:/tmp$ ll | grep test
-rw-rw-r--  1 scott scott     0 Jul 19 15:34 test0
-rw-rw-r--  1 scott scott     0 Jul 19 15:34 test1
Notice that when I made a file using sudo, it didn't make the file as root or any other account, the action was taken by the same account. Just in one case access to privileges was allowed and in the other case it was protected. But the account itself has the privileges in this case, just administered by the sudo mechanism.
A little test on my Fedora 34
That's weird. Why is it one way on Ubuntu and one way on Fedora?

I did a test on a fresh Ubuntu Server 21.04 install. For me it behaves the same as Fedora. Top example was before I set NOPASSWD:ALL on the sudo group.

scottalanmiller

@jaredbusch said in sudo problems:

@scottalanmiller said in sudo problems:

@jaredbusch said in sudo problems:

@scottalanmiller said in sudo problems:

@pete-s said in sudo problems:

We want to move to using ssh certificates on our servers and remove all passwords.

That's what we do.

Since when? What do you use to manage and generate certificates?

Generate with ssh-keygen. Manage with a wiki. We are only so big, so it works fine.

That is not certificates. That is keys. Completely different.

Oh yeah, not enough coffee this morning.

JaredBusch

@pete-s said in sudo problems:

@jaredbusch said in sudo problems:

@scottalanmiller said in sudo problems:

@jaredbusch said in sudo problems:

@scottalanmiller said in sudo problems:

@pete-s said in sudo problems:

We want to move to using ssh certificates on our servers and remove all passwords.

That's what we do.

Since when? What do you use to manage and generate certificates?

Generate with ssh-keygen. Manage with a wiki. We are only so big, so it works fine.

That is not certificates. That is keys. Completely different.

I don't know what @scottalanmiller uses but ssh-keygen is used to generate ssh certificates as well.

From the man page:
ssh-keygen supports signing of keys to produce certificates that may be used for user or host authentication. Certificates consist of a public key, some identity information, zero or more principal (user or host) names and a set of options that are signed by a Certification Authority (CA) key. Clients or servers may then trust only the CA key and verify its signature on a certificate rather than trusting many user/host keys. Note that OpenSSH certificates are a different, and much simpler, format to the X.509 certificates used in ssl(8).

But if you are automating certificate generation, you need to wrap this in something.

No, ssh-keygen does not do this (ssh certificate generation).

As you highlight, it can be used as part of the certificate process. But it cannot, and never will, be the certificate authority. Thus it is not the tool for this this.

1337

@jaredbusch said in sudo problems:

@pete-s said in sudo problems:

@jaredbusch said in sudo problems:

@scottalanmiller said in sudo problems:

@jaredbusch said in sudo problems:

@scottalanmiller said in sudo problems:

@pete-s said in sudo problems:

We want to move to using ssh certificates on our servers and remove all passwords.

That's what we do.

Since when? What do you use to manage and generate certificates?

Generate with ssh-keygen. Manage with a wiki. We are only so big, so it works fine.

That is not certificates. That is keys. Completely different.

I don't know what @scottalanmiller uses but ssh-keygen is used to generate ssh certificates as well.

From the man page:
ssh-keygen supports signing of keys to produce certificates that may be used for user or host authentication. Certificates consist of a public key, some identity information, zero or more principal (user or host) names and a set of options that are signed by a Certification Authority (CA) key. Clients or servers may then trust only the CA key and verify its signature on a certificate rather than trusting many user/host keys. Note that OpenSSH certificates are a different, and much simpler, format to the X.509 certificates used in ssl(8).

But if you are automating certificate generation, you need to wrap this in something.

No, ssh-keygen does not do this (ssh certificate generation).

As you highlight, it can be used as part of the certificate process. But it cannot, and never will, be the certificate authority. Thus it is not the tool for this this.

You're actually mistaken because I've done it many times now. A Certification Authority, when it comes to openssh certificates, is really just a key pair that you carefully guard.

You create certificates by using the CA keys to sign other public keys from users and hosts. The result is a certificate named *-cert.pub

And you do all of this with the ssh-keygen utility.

Similar to how you can create CA and everything else for the more complex x509 certificates with just openssl.