Hi Stefan, Much appreciate the feedback. I'm going to assimilate a lot of it into the article I'll eventually post on the site. As for the extra tech details though, like I said in the opening paragraph, I prefer not to give all those details. If someone does not know where sshd_config is and how to restart ssh, they will more likely then not break something or lock themselves out of their own box.. (remote iptables changes anyone...). I have issues with sites like howtoforge that go into every nitpicking detail. Do people really learn about what they are doing by using those instructions? Blindly following someone else's instructions without doing at least a bit of digging into what they are saying is just plain dangerous. Maybe I am simply from a past generation that learned from fixing the things we broke as apposed to re-installing the OS because a re-install was a real PITA. :) (Shit, I'm not that old.. am I) Anyways, sometime between now and eventually, I'll fix up the article and post it to the site. Please feel free to make comments on the post and add whatever extra details you would like.
Again... thank you very much for the feedback. Jimmy On Thu, Nov 26, 2009 at 8:59 AM, Stefan Monnier <[email protected]> wrote: >> - create your users key pair on your workstation > ^^^^^ > user's > > It may seem like a nitpick, but the plural form could almost make sense > and mean soimething else, for someone who doesn't know anything about > the subject. > >> ssh-keygen -t dsa -b 1024 > > "-b 1024" is the default (if not the only valid value, according to the > manpage) for DSA, so you can drop it. > >> - copy the public key securely to your destination server and put it >> in ~/.ssh/authorized_keys2 > > Say explicitly ~/.ssh/id_dsa.pub and say *how* to put in the file. > BTW, I recommend you use ~/.ssh/authorized_keys without the 2: it's the > canonical name and "man authorized_keys" works whereas "man > authorized_keys2" doesn't. > >> - don't forget to set the correct permissions (number one reason why >> this does not work) >> chmod 700 ~/.ssh >> chmod 600 ~/.ssh/authorized_keys2 > > AFAIK, authorized_keys doesn't need to be 600 (mine is 644 and seems to > work just fine). The best way to get the right permissions on .ssh is > to not make it yourself but let SSH create it for you. A good way to > create it is to do "ssh-keygen -t dsa". There's no reason not to create > such a key-pair on every one of your machines. > >> - in sshd_config set: >> PasswordAuthentication no > > It's unlikely that your user's working directory will be /etc/ssh at > this point, so better say explicitly /etc/ssh/sshd_config. Of course, > this needs to be done as root, which you may want to mention as well. > >> - restart ssh > > Say how. On my Debian machines it's "/etc/init.d/ssh restart", but > I don't know how universal this is (IIRC it's been > /etc/init.d/ssh-server or /etc/init.d/openssh or something at some point > in the past). > >> Finally, now that you know what user you will always be using to login >> to your server, make sure ONLY that user can ever login. This is a >> little more drastic and can have some evil side affects, but I will > ^^^^^^^ > effects > > -- Stefan > _______________________________________________ > mlug mailing list > [email protected] > https://listes.koumbit.net/cgi-bin/mailman/listinfo/mlug-listserv.mlug.ca > _______________________________________________ mlug mailing list [email protected] https://listes.koumbit.net/cgi-bin/mailman/listinfo/mlug-listserv.mlug.ca
