Subtitles of the Movie

In this video we'll show you how to create and manage a Secure Shell private and public keypair. The way we do it will allow secure log-ins with a passphrase. The passphrase is not transmitted over the network, reducing your risk from crackers. You can even configure it to allow secure log-ins without a password. Let's create a keypair using the ssh dash keygen command. The two commands shown here can help you create DSA or RSA keys. Let's create a pair of dsa keys. If I enter a passphrase I'll need to enter that same passphrase once I've configured the system. And that passphrase will be required for log-ins to the remote SSH server. If I didn't use a passphrase, then the secure log-in would proceed, once properly configured, without a password. Note how the shh keygen command created the private public key pair in the dot ssh subdirectory. In this case, the private key is id underscore dsa, and the public key is the same filename with the dot pub extension. To proceed, we can copy the key to the remote system, the public key. For this purpose I like to use the scp command, but you could use the command of your choice. We copy the public key to the remote system, and then I go to the remote system and use that public key and append its contents to the ssh slash authorized underscore keys file. If there's no such file currently existing, just create it. You may even need to create the SSH directory. There we go. To prepare the system on the SSH server, the system to which you want to connect remotely, you need to make sure appropriate permissions are configured. First, in this case, I need to make sure that Donna's home directory is set up with 700 permissions. In other words, it should be limited to 700 permissions, or read-write and execute permissions just for the owner of the directory. That's better, and I need the same permissions on the SSH subdirectory. There we go. And finally, I need read and write permissions on the authorized key file. Of course, I need to make sure that the Secure Shell server is actually started on that system. And that's running. Now I can go back to the original system, and let me do this from a different account since I've already sent it out from my home account. I can, in this case, substitute the IP address of the remote system and since I used a passphrase before for our dsa key, I enter that passphrase, and it logs me into the remote system. Let's try this again, on a system where I did not use a passphrase. It logs me in directly without requesting any sort of password. If there are problems, or if you simply want to know more about the process, try it with the dash v switch. This tells me that the public key was accepted by the server, and it was used to verify my log-in. No password was sent over the network, thus there's less for a cracker to break into your system with.