I'll explain how signatures involving elliptic curves work. Cryptocurrencies mostly use elliptic curves due to the smaller size of signatures that need to be published on the blockchain.
When a private key, which is just a large integer, is mapped to a public key (which is a point on a specified elliptic curve), this mapping has certain useful mathematical properties. Note that this mapping is done in such a way that it is "one way". You can easily map from the private key to the public key elliptic curve point, but you can't practically reverse that operation.
Firstly, an elliptic curve is chosen because the points on the elliptic curve will form an Abelian group under an operation that we call "addition". This means you can do what looks like simple algebra with the points. You can take points $A$ and $B$, add them to get point $C$, and you will be able to observe that $A+B==B+A$. Note that we only define addition and subtraction operations, and we can't "multiply" points or "divide" points with other points.
Secondly, the mappings of private key integers to points are "additively homomorphic". This means if you have the private keys $a$ and $b$, which map to the public keys $A$ and $B$, then the public key of $a+b$ will be equal to the point $A+B$.
The mapping of a private key to a public key is simply to take a private key $a$ and calculate the public key $aG$, which means to add the well-known point $G$ to itself $a$ times. It would take forever to calculate this by adding $G$ to itself $a$ times, but there are mathematical shortcuts we can use to do this quickly. Since these shortcuts only exist to perform the multiplication quickly but not to go backwards and determine the private key from whatever the multiplication result is, this mapping is a one-way function.
Now, imagine that I have the private key $a$ and the public key $A=aG$, and you present a challenge to me. You come up with a random private key integer $x$, and you ask me to give you a response integer $y$ such that you can verify that $xA==yG$. I will only be able to pass your challenge if I know the private key $a$, which would allow me to calculate $y=xa$. This would verify because then $xA==xaG==yG$.
What I've described above has two flaws. The first is that once I pass the challenge, you can easily then calculate my private key $a$ as $y/x$.
The second flaw is that I need you to provide me with a challenge, rather than simply being able to provide you with a signature without having to interact with you.
The first flaw is addressed by including a "blinding factor", which allows me to pass the challenge without revealing my private key. For example, with a Schnorr signature, I pick a random private key $k$, reveal only $K=kG$, and then ask you for your challenge $x$. Then I produce a value $y$ such that you can verify that $xA==K+yG$. Now, after I reveal $y$ to pass the challenge, you know that I could have only calculated $y$ with knowledge of my private key $a$, but you can't calculate my private key without knowing my secret blinding factor $k$.
The second flaw is addressed by using the Fiat–Shamir heuristic to create a challenge using a function serving as a "Random Oracle" that allows me to come up with the random challenge without a way to cheat. In the case of the ECDSA signature scheme, this function output is the x-coordinate of a public key mapped from a particular input. In the case of a Schnorr signature, the function is a cryptographically secure hash such as SHA512/256.