I was about to downvote this for being obviously false, but after some research this does appear to be true, because ssh uses some channel binding mechanism to prevent your public key authentication from being replayed/reused by the "man" in the middle.
This is one of those situations where it's necessary to be very precise about the security properties.
Specifically, if you bind authentication to the connection, then an attacker who impersonates the server (in this case because it's the first connection, but in other settings because they have a fake certificate), then client authentication is not portable to another connection, so the attacker can't mount a classic MITM attack. However -- and this is a big however -- that doesn't mean that there aren't serious security problems. For example:
* If you use SSH to copy a secret such as an API key to the server, then the attacker still knows the API key.
* If you download some file (e.g., a script) from the server and then trust it, the attacker can use that to provide a malicious script.
>* If you use SSH to copy a secret such as an API key to the server, then the attacker still knows the API key.
That's much harder to pull off though, because you need to replicate the environment close enough so that the victim doesn't suspect anything. Do they put their config files in /var/lib or random docker volumes? Do they use docker compose or docker-compose, etc.
If you know its their first connection to a fresh VPS and assume they haven't used a web-based display to set up anything yet, you just need to guess their install image, which is probably off-the-shelf.
Basically, the client signs the shared key obtained through Diffie-Hellman key exchange, which then gets verified by the server. This ensures that the client and the server have the same shared key, hence no man-in-the-middle.
As a former physicist with a PhD in experimental condensed matter physics, I would say that this is one of the dumbest things I have ever seen. I suspect COVID-19 made people collectively dumber.
You should not use JWT if you have a single application in your organization. However, whenever you have multiple applications, you need some form of central authentication / authorization service. Otherwise, you would have to maintain auth databases in each application, each application will need to be logged-in separately, you won't be able to implement a simple "suspend a user's accounts after X unsuccessful auth attempt", you won't have a central auth log.
Comparing background radiation to exposure from artificial radiation sources does not sound right to me. The background radiation is absorbed relatively evenly by the body surface. However, various artificial radiation exposure is local, such as dental x-rays or CT, which, for example, will increase the thyroid cancer risk at seemingly small exposure levels compared to cosmic radiation exposure.
reply