It finally finished..
5624900b-cb96-41ee-b8f1-29373e262692-image.png

While I was waiting, I looked at pvecm status and found out it thought I had 4 nodes (see expected votes), when I only have 2 nodes.

76a4d9f9-18ba-4fe5-af47-4ea037892bfc-image.png

I used pvecm expected 2 on both and suddenly the updates moved on and I was able to log in to the web interface immediately.
d5ecd18f-8e07-4222-afea-0b04d215775c-image.png

In the web interface, it showed a pve3 and pve4. These were some test setups I did months ago.
I deleted the nodes from the CLI and everything looks clean again.
782c49e5-1457-499d-8c58-5afbc3c2efda-image.png

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

OpenSSH can use host certificates to verify the host (like SSL certs on a webserver). OpenSSH can also use user certificates to verify the user (like passwords or ssh keys).

Both these types of cert to be used independently of each other.

I've tested using user certificates to authorize user login, since that is what most
people do with keys. People never really verify the host identity.

It works great and it's actually very simple. This will be my new SOP going forward.

Before starting to add hosts and users you need to create a Certificate Authority (CA) - which is actually just a key pair. It's a one-liner.

Every time you create a new host, you just need to copy the same file to it - the public key of the CA. And change one line in sshd_config to allow ssh certificates.

Every time you have a new user on your team who need access to servers, you have to generate a certificate for him. It's a one liner. He will copy the certificate to his own machine. And the ssh client will automatically send the certificate when needed.

Generating certificates is the part that could be automated. You could for instance be given a certificate that expires in 5 minutes. That would allow you to login and stay logged in. But if you need to login again, you need to generate a new certificate.

@Dashrender said in O365 Outbound email issue:

@JaredBusch said in O365 Outbound email issue:

For the record, even though I made the above connector and it failed to verify, I did save the connector. Apparently, that was enough as email is sending now.

So which connector is solving this - the TLS regardless of cert condition, or the No-TLS

I only left the TLS regardless of cert, so it has to be that one.

@flaxking said in SSL/TLS client certificates questions:

Domain name doesn't matter, unless you're signing with a public CA. I'd think self-signed vs internal CA vs public CA would depend on what the authentication mechanism supports and how you have to manage the certificates. (i.e. if there are going to be a ton of them it might be easier for the authentication mechanism just to trust certificates signed by a certain internal CA rather than having to make each certificate trusted.

From what I've seen so far, I've come to the same conclusion.

I had some confusion because of the age of the old CSR. It doesn't line up with the correct dates. I'll edit my original post when I know more.

@aaronstuder said in How to setup Nginx TLS certificate based Authentication (VPN alternative):

@emad-r 3650 🙂

One of the main reasons that normal certs cannot be bought with forever expiration is because then people would be less apt to update them as ciphers are broken.

Look at how many people still use(d) SSLv1 SHA1, etc., long after they were proven broken.