In a struggle to secure my home computer I did battle with the ssh server once again to configure it \u201cjust the way I want it\u201d \u2122. I prefer pubkey + password since this ensures that if I lose the laptop\/phone\/whatever then the lucky finder will not find his\/her way into my home computer.<\/p>\n\n\n\n
So, without further fanfare here are various bits that need to be done.<\/p>\n\n\n\n
Configuring the ssh server<\/strong> And of course there a bunch of authentication protocols that are not needed: Creating the keys<\/strong> I used In the same folder on the server create a file called When creating the key pair you will be prompted for a pass phrase. This is where you choose whether or not you will need a pass phrase (which acts as a password) in order to access this account. If you leave the pass phrase empty you\u2019re allowing key only access with no password which is dangerous since if anyone gets a hold of your roaming device he\/she can access your account with no extra data.<\/p>\n\n\n\n Distributing the keys<\/strong> Note:<\/strong> In a struggle to secure my home computer I did battle with the ssh server once again to configure it \u201cjust the way I want it\u201d \u2122. I prefer pubkey + password since this ensures that if I lose the laptop\/phone\/whatever then the lucky finder will not find his\/her way into my home computer. So, … <\/p>\n
edit \/etc\/ssh\/sshd_config<\/code> and use the following entries:Protocol 2 # protocol 1 is outdated
PubkeyAuthentication yes # I want public key to be used for authentication (and possibly to be combined with a pass phrase)
<\/code><\/p>\n\n\n\nChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no
PasswordAuthentication no
UsePAM no
<\/code><\/p>\n\n\n\n
Still on the server in the home folder of the user you want to login remotely with, create the private\/public pair using ssh-keygen -t dsa<\/code> in ~\/.ssh<\/code> (the default location for ssh-keygen). You get two files: id_dsa<\/code> (private key) and id_dsa.pub<\/code> (public key).<\/p>\n\n\n\ndsa<\/code> keys in this post and you can use rsa<\/code> keys if you pass -t rsa<\/code> to ssh-keygen<\/code>.<\/p>\n\n\n\nauthorized_keys<\/code> which has the public key (it can just be a copy of id_dsa.pub<\/code> but has the potential to contain many keys \u2013 possibly one per user that can connect to said account or one per roaming device).<\/p>\n\n\n\n
Copy the private key ~\/.ssh\/id_dsa<\/code> to the roaming devices you want to access the server from (laptop, phone, whatever). If the roaming device is a Linux box then put the private key in the same location (~\/.ssh\/id_dsa<\/code>) in the home folder of the user that wishes to access the server. If you are using some other ssl tool besides command line ssh on a Linux box to access the server then it should have a place where you plug the private key into. If it doesn\u2019t have such a place then dump it. Putty (a widely used ssh client on windows) has an option to use a private key for connection.<\/p>\n\n\n\n
While trying this out a lot of people seem to fail because they do all the experimentation on a desktop. In a desktop there is a system called ssh-agent<\/code> which does the authentication for you in order to save you typing the same password multiple times. This agent is a problem when doing experimentation since it needs to be notified that you switched keys. So, every time you switch keys (regenerate the ~\/.ssh\/{id_dsa,id_dsa.pub}<\/code> files) you need to run ssh-add<\/code> to let the agent know this. Another option is not do all of the experimentation from a desktop but rather from a login shell (Ctrl+Alt+1<\/code> or whatever) so that the agent does not come into the game (which is complicated enough without it). Only after everything is setup re login to the graphical desktop and try everything out.<\/p>\n","protected":false},"excerpt":{"rendered":"