Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Click here to return to the 'Modify Remote Login server to block scripted attacks' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Modify Remote Login server to block scripted attacks
Authored by: surf on Feb 12, '05 03:15:17PM

As to expand on the public/private mechanism:

It is a combination of two things: the private/public key-pair and a asymetric cryptoalgorithm.

If you encript data with the public key (PUB), you can only decrypt it with the private key (PRI), not with the PUB itself or some other key. And the other way round.

So you can freely give away the PUB. When someone encrypts a message with it, only you, having the secret PRI key, can decrypt it.

So you transfer the PUB to the server.

Then you connect to the server using ssh.

The server encrypts some data with PUB and sends it to you. Only you can decrypt it using PRI. So you now have the plain data.

You then encrypt it with PRI and send it back to the server. It can only be decrypted with PUB and the server does so.

It then checks if the data is the same as the data it has send to you. If it is, it knows it is really you, as only you, the holder of PRI, could have decrypted and reenrypted the data so it "survives" the roundtrip.

Data_A ==> encrypt with PUB ---send to client---> decrypt with PRI ==> Data_A

Data_A ==> encrypt with PRI ---send to server---> decrypt with PUB ==> Data_A

--> Data_A sent, Data_A received ==> OK, this is the user.

Now, someone tries to connect, he does not have the real PRI key:

Data_A ==> encrypt with PUB ---send to client---> decrypt with FALSE_PRI ==> Data_B

Data_B ==> encrypt with FALSE_PRI ---send to server---> decrypt with PUB ==> Data_C

Data_A sent, Data_C received ==> This is not the user, login refused

So it basically checks, if the user connecting is the one having the matching PRI key to the PUB key he left at the server.

[ Reply to This | # ]