the rsa/dsa key generation is only for identifing the host. not for logging in
to log in you need to generate a key and put half of it (the public half) on the server you want to log into and the rest (the private part) somewhere safe.
i put my keys on a flashdisk. this is not that safe as anyone can read a flashdisk when its plugged in (unless you tweak /prooc/usb for a multihead setup so that some users get acsess to some usb port, i havent tested that) i do keep them encrypted so that they need to be decrypted in ram so that no one else can just copy them off unlsess they are root. they could do a offline attack however but thats beyond the scope of this post
so you want to genetare a rsa key pair. well go somewhere on your fs thats "clean" or create a folder and change your current dir to there (cmd line here) and run ssh-keygen.
follow the prompts. i recomend you change the name. it isnt a requirement but i dont want to clober my keys in the futre. i also generate a diffrent key for each host i use however the added benifits of this are slight. it dosent cost me however so i do it. ill come back to that latter
well i suppose you entered a name instead of a path for the keyfile which is what you would want if you want the files in the current directory. if not for the rest of this tut the keys are in your .ssh folder it your /home dir
now the fun part. you have to get the <key file>.pub to your Z somehow. eaist way is to log in via ssh like this. cat <path to public key> | ssh <user>@<host> "touch ~/.ssh/authorized_keys | tee !$"
what i did is cat the public key, pipe that as standard input to ssh. on the Z what happens is ssh logs in, creates the authorised keys file if its not been created and takes the standard input from the box you are working on and adds it to the allowed keys for this user list
congratulations you are now half way there
ok now you half to execute "eval `ssh-agent`" (note the backticks, we need a shell for ssh-agent) OR "eval $((ssh-agent))" which is the posix version (its a history lesson kids )
this launches a authentication proxy for you. its goal is to collect your ssh keys and store them. not that handy if you didnt put a password on your key (shame on you) but really handy if you did as you only have to type the pass once.
add the private key with ssh-add <path to private key> (the one without .pub).
now ssh into your box . it shouldnt ask for a password
this is just stage one. you can take it futher if you want and i am willing to write the guides if someone wants it. as i have stated before it mainly increses security by disabling 3des encryption and using blowfish or AES-256-cbc, adds session sharing (poor mans ssh-agent and faster loging times as well as less conections) and compresion of everything thats goes throgh the link (best on slow WANs, some people like to only do it manually but i fuigure it dosent hurt unless you are doing file transfer to somthing without much cpu grunt like the Z over usb)
also a guide to allowingpublic key logins and hardeneing your ssh server could be written too if i am up to it and there is demand
now back to some issues, i use 1 key per srever. you can use the one id for every server if you wish however i like it my way as when i am on a windows PC i can give it only the certs i need to get the job done so if someone reads its mem they wont get all the keys
the other hand reason is that it makes ssh-agent proxying alot safer, if you create a seperate ssh-keychain instance with only node B and node C (if you are on A and can only see B but B can see C) then you only add 2 keys and you can enable fowarding to your hearts content knowing thatnot every server you can connect to will be comprimised if someone has hacked that box (as only B and Cs keys have been put on the keychain
just aquick word about the proxy thing, that means when you logg into B from A, B can reuse the ssh-keychain and the keys on its keychain to log into C without a password, if the kys to D were on it and the bok got hacked then someone with your privs or root could then tell a ssh session to authenticate to the ssh-agent onA to log into D
confused?, i know i was. it clicks once you have mastered the basics
you might want to try X fowarding, add -X to your ssh prog (ie ssh -X <user>@<host>. now any X app on your Z will run on you PCs monitor, but exectue on the Z. makes editing text files fun and is best used with a usb flashdisk with putty and an X server on it. meaning you can do stuff on your work pc knowing that the progs on the Z (security) or that the data is on your Z (portability). it also means you then get cross platform compatability as you then have an X server for nearly evrey OS on the market (macos, unix and clones, windows)
might tell you about the "revers ssh" that i suggested else where to bypass a firewall, basically its a good use of port fowarding.
you connect the port on a machine A (the Z for eg) that connects to ssh (127.0.0.1:22) to a port on a remote machine (eg 2222), you then ssh into port 2222 on the proxy machine © from your PC (. this will mean that you have just ssh'd into the Z (ssh from B to C, then wrap it in another ssh session and onto A)
note that thats cpu intensive as it does 2 ssh sessions. B (your laptop) and C (the proxy) will only do one but A (the Z) will have to do 2 of them. this can kill a Z if transfering files but is fine for ssh work. not sure about X as i never did any bandwidth testing on it but pretend its a 8mbit linx (overhead) with near lan latency (near lan because ssh add latency, even more so when overloaded)
