I would like to set up SSH so that you have to have a key generated by my server to connect. I have found a bunch of information about generating keys, but none about actually setting this kind of thing up. Is there a howto I can read somewhere?

I think what you would ideally want is ssh to work with a trusted CA authority (set up your own OpenSSL server, issue certs and only trust certs issued by that CA).

I don''t think SSH supports this.

I haven''t tried it, but you could do this:

edit your sshd_config file, set "PasswordAuthentication" to "no". Set "PubKeyAuthentication" to "yes".

Then you need to add each key you want to be able to log in to that user to their $HOME/.ssh/authorized-keys file. Check a "man ssh" to get more info on how this works.

This should prevent any password logins and require the PubKey to even log in. You''ll have to set up your ssh clients to use the private key you authorize to connect to your server with that key. They won''t get a password prompt, just an immediate shell.

Usually you don''t stop password logins and users who don''t want to type their passwords will add their public key to their authorized-keys file, so they can get single-sign-on of sorts to their Unix boxes. But I don''t think this is exactly what you want.

Not as eloquent in my mind. I wonder if there is some enhancement to SSH to work with Certifciate Authorities and Trusted Root certs.

Interim.

Everything you described works like what I want ecpect I want to disable password logons. I want me and only me to be able to logon to my home system. I will have to try what you have described later, I would ssh in now by my system seems to have gone down for some unexplicable reason.

In that case, it should work. You can also check out the DenyUser and DenyGroup in sshd_config, that might do what you want as well (only allow yourself).

Interim.

Thanks for the help, I was able to get everything setup exactly how I want.

Just curious , what method did you use?

Int.

Actually I''m having some problems now. I was able to ssh to/from my box, but now that I''m at school it isn''t working. I disabled password authentication, and only left open RSA authentication. I have the key here, I''m running ssh in verbose mode, but when it sends the public key packet it just moves on and trys another authentication method. I''ve checked my permmissions, everything seems to be in order, I guess I''ll have to wait till I get home to fix it.

Did you ssh from the same box back on itself?

Watch your /etc/hosts.deny and /etc/hosts.allow ( I think those are the files that SSH checks for allowed IPs to connect ).

I''m assuming you added that key to the authorized_keys file?

Okay, I think I have everything working now....with one really really big hang up. I'm on the client right how and I only have the public key, is the the one I'm supposed to have? When I try to connect it asks for my my pass phrase, when I enter it I am told that I have entered a bad passphrase. I know for certain I am entering the correct one. Should I have the private key on my laptop?

[edited by - griffenjam on September 4, 2003 7:56:30 PM]

On your client, you want your private key. On the server, your public key.

You just cat identity.pub >> .ssh/authorized_keys.

Usually, people maintain password auth, log in, then copy their public key upto the server, and set up authorized_keys...log out, and enjoy no password logins to their servers.

In your case, you''re sort of forcing it to rely on authorized_keys, so it will achive your goal of only allowing key holders who are authorized to log in.

So, generate your public and private key, put both on a floppy, then add your public key to your account''s .ssh/authorized_keys. At school, copy your private key (probably "identity") to your .ssh/identity file on your machine at school and you can connect.

If you don''t own that machine at work, you probably want to make an effort to clean up your identity file after use. Maybe set up a bashrc script to copy it from a floppy, then erase it on logoff. Or just make sure you set your permissions tightly to prevent people from getting your key. You might also want to make sure you generate your key with a very tough passphrase, since you''re not really interested in single sign on, but tighter security.

That way your key can''t be used to connect without both the private key (identity file) and your tough passphrase. Use a full sentence, making it hard to crack.

Int.