Presentation on theme: "SOI-ASIA Unofficial Operators Meeting 10 May 2004."— Presentation transcript:
SOI-ASIA Unofficial Operators Meeting email@example.com 10 May 2004
AI3 Security Policy Basics –Moderately independent site by site –Self defense
User Account Management Account creation –No user password for local operators –If necessary, allow user password for foreign operators A case when we allow user password –A foreign operator needs root authority –Su2 / sudo An operator can be root by user password without root password
Remote Access Administration SSH –Prohibit root login –Prohibit password authentication –Use public key authentication RSA authentication for SSH1 RSA or DSA authentication for SSH2
RSA / DSA Public key authentication methods RSA (Rivest, Shamir, Adleman) –Developed based on the difficulty of factorization into prime factors from a large number DSA (Digital Signature Algorithm) –Expanded beyond ElGamal
Actual Work Flow New User Host Operator Create RSA / DSA key pair (1) Request a new account with attaching the public key Create a new account and put the public key in the host (2) Try the new account (3) Send notification
Step 1: Create RSA/DSA Key Pair On Windows PC –Use puttygen On Unix PC –Use ssh-keygen of OpenSSH suite Do we have to create many pairs of RSA/DSA key for every remote host? –I dont think so. –Private Key has to be safely kept on your PC. –Public Key can be shared on remote host. Put the public key on the WEB site? Send the public key by e-mail?
Step 2: Create a new account and put the public key in the host Where do we put the public key? –~/.ssh/ What is the file name? –~/.ssh/authorized_keys What point do we have to take care? –The owner of authorized_keys should be the correct user.
Your consent to our cookies if you continue to use this website.