The account is the same as you create in any acme client. I don't see potential for a reverse lookup.

I think the previous post is talking about a search that will find the sibling domain names that have obtained certificates with the same account ID. That is a strong indication that those domains are in the same certificate renewal pipeline, most likely on the same physical/virtual server.

Run ACME inside a Docker container, one instance (and credentials) for each domain name. Doesn't consume much resources. The real problem is IP addresses anyway, CT logs "thankfully" feed information to every bad actor in real time, which makes data mining trivially easy.

you dont even need a docker container to do that.

Agreed, that's just a personal preference thing of me. Harder to mess up and easier to route.

This is publicly publishing the account ID. There is an optional extension in RFC8659 that extends it but it isn't required by any implementer. This puts that ID into a public well known location that is easy to scrape and will be (this is exactly the kind of opsec info project like Maltego love to go lookup and pull in).

All of those alternatives don't have voice chat in the way discord has (or Teamspeak/Mumble).

Good bye. Discord is not trustworthy with this kind of data. As proven recently.

Depending on what you configured. It can also keep the mail on the server.

who would use this?

Very resource constrained systems, systems where consistent admin between *BSD and Linux is important. Containers where you have reasons to break the single process practice.

Your phone. Haven't looked into Android images for at least a decade but it was just simple bash scripts back then.

My phone does not run Devuan.

People who hate idiots that put the verb before the noun.

I have never seen this happen.

I have however experienced that a ISP will write to you because you have a faulty modem (some Huawei device) and asks you to not use it anymore.

Visit eBay and search for "blocked IMEI" or variants. There are plenty of used phones which are IMEI locked due to either: reported lost, reported stolen, failed to make payments, etc.

All offers seem to be from the US.

I the lines between IMEI banning or blacklisting and the modern unlocking techniques they use have been blurred a little bit and so some carriers and some manufacturers don't really want to do or spend time doing the IMEI stuff and would prefer to just handle it all via their own unlocking and locking mechanisms.

it's all lowercase anyway at parse time.

rate-limit-remaining would be nicer than ratelimit-remaining

only if looping information is stored inside the container.

Bug tracker where they lied about "not enough interest".

change port.

After years of cargo-culting this advice—"run ssh on a nonstandard port"—I gave up and reverted to 22 because ssh being on nonstandard ports didn't change the volume of access attempts in the slightest. It was thousands per day on port 22, and thousands per day on port anything-else-i-changed-it-to.

It's worth an assessment of what you _think_ running ssh on a nonstandard port protects you against, and what it's actually doing. It won't stop anything other than the lightest and most casual script-based shotgun attacks, and it won't help you if someone is attempting to exploit an actual-for-real vuln in the ssh authentication or login process. And although I'm aware the plural of "anecdote" isn't "data," it sure as hell didn't reduce the volume of login attempts.

Public key-only auth + strict allowlists will do a lot more for your security posture. If you feel like ssh is using enough CPU rejecting bad login attempts to actually make you notice, stick it behind wireguard or set up port-knocking.

And sure, put it on a nonstandard port, if it makes you feel better. But it doesn't really do much, and anyone hitting your host up with censys.io or any other assessment tool will see your nonstandard ssh port instantly.

Conversely, what do you gain by using a standard port?

Now, I do agree a non-standard port is not a security tool, but it doesn't hurt running a random high-number port.

> Conversely, what do you gain by using a standard port?

One less setup step in the runbook, one less thing to remember. But I agree, it doesn't hurt! It just doesn't really help, either.

it did for me.

I've tried using a nonstandard port but I still see a bunch of IPs getting banned, with the added downside of if I'm on the go sometimes I don't remember the port

Underrated reply - I randomize the default ports everywhere I can, really cuts down on brute force/credential stuffing attempts.

or keep the port and move to IPv6 only.