Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I use public-key authentication with secureCRT to login linux server and turn off password authentication at these server:

1.Create the keypair(openssh key format) with SecureCRT.

2.Cat the public key named identity.pub to the $HOME/.ssh/authorized_keys.

3.In to the SSH2 category of Session Options of a server, select the PublicKey option in the Authentication section, then press the Properties button,in the Properties dialog, select the Use session public key setting ,then find the Use identity or certificate file section, and press the file browser button (…),then I select the private key named identity.

4.then I can login this server by using SecureCRT and entering the password of the keypair,that's all well.

BUT:

On another server, everything is the same on the server. But in SecureCRT, instead of selecting the private key named identity, I instead selected the public key named identity.pub. Despite this, I could still login in the same way.

I don't understand how this is possible.

The right is secureCRT use private key to matching the public key at the server? is it ?

share|improve this question
    
I tried to clarify your question, but I didn't understand the last sentence at all. –  Jenny D May 8 '13 at 10:04

2 Answers 2

If I understand your question properly, then yes - you must tell SecureCRT to use the private key, not the public key. Then, when you go to login, this happens:

  1. Your client (in this case SecureCRT) starts a connection to the server, and says "hey, I want to login as user glancesx".

  2. The server says "sure, if you can prove to me that you really are glancesx". Here's a bunch of data (a "challenge") that I want you to encrypt and send back to me with a key that I can verify.

  3. The client uses the private key to mathematically sign the challenge and sends it back to the server.

  4. The server says "Thanks; let me check the authorized_keys file for glancesx to see if you've used a key that glancesx wants me to trust". If it finds any key that matches the encrypted data you've sent back, you will be allowed in.

So the whole point here is that there must be two parts of the key - one on the client side ('identity'), and one on the server side ('identity.pub'). Data that is signed with the one can be verified with the other.

share|improve this answer
    
I think so too. but my question is why the client side('identity.pub') can matching the server side('identity.pub') correctly(could login very well)? –  glancesx May 8 '13 at 9:30
    
Ah, I misunderstood the question. That shouldn't be possible - I'd very much like to see the auth logs from the server where that happened. –  Jenny D May 8 '13 at 9:45
    
It might simply be that SecureCRT understands the difference betweeen private and public keys, and will use the correct private key for the public key you selected. –  Jenny D May 8 '13 at 9:47
    
Oh,sorry for my bad english. That's incredible. I am sure that operation is all correct. which log you want to see ? of secureCRT or the server? :-) –  glancesx May 8 '13 at 12:04
    
SecureCRT to start with - I'm not really familiar with it. –  Jenny D May 9 '13 at 5:45

You must distribute the public key to the servers you want to login (.pub file), and keep the private part in the client you want log from (keep the pub file there too, you'll need it in the future to log another server).

From a linux machine with openssh, you can use ssh-copy-id -i keyfile.pub user@server to distribute the pub part of the key to the servers.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.