Mastering SSH: Strong Password-less Logins - page 2
Connecting For the First Time
Continued from Page 1.
In order to use a public/private key pair, you have to create it. You can do so from a command line by using the ssh-keygen utility. There are many options that you can pass to ssh-keygen including the type of key, the filename you want it to create, and a comment for the key file, but you can also just roll with the defaults. Here is the result of calling ssh-keygen with no arguments:
dink:~ jmjones$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/jmjones/.ssh/id_rsa):
Created directory '/Users/jmjones/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/jmjones/.ssh/id_rsa.
Your public key has been saved in /Users/jmjones/.ssh/id_rsa.pub.
The key fingerprint is:
The key's randomart image is:
+--[ RSA 2048]----+
| . S . |
| + o . . . . |
| E o o + o |
| o o . = *.. |
| ... .=Xoo.. |
I accepted the default "id_rsa" as my key file. I also accepted the default of not putting a passphrase on the file. If I had chosen to add a passphrase to the file, I would be prompted for the password each time I used it. Two files were created in $HOME/.ssh as a result of running ssh-keygen:
dink:~ jmjones$ ls -l ~/.ssh/
-rw------- 1 jmjones staff 1675 Dec 30 17:37 id_rsa
-rw-r--r-- 1 jmjones staff 400 Dec 30 17:37 id_rsa.pub
"id_rsa" is my private key. I don't want anyone to get access to this file, otherwise they could pretend that they are me. Notice that the permissions are more restrictive on "id_rsa" than on "id_rsa.pub." "id_rsa.pub" is my public key. I can circulate this file to anyone that I am interested in connecting to. Don't worry; no one can reverse it and determine what your private key is.
If I want to use this key with the server in the previous examples, I would place the contents of my public key ("id_rsa.pub") into the file "$HOME/.ssh/authorized_keys" on the remote server. In order to set this up, I typically ssh to the remote server and copy/paste the contents of my local "id_rsa.pub" file to the remote "authorized_keys" like this:
jmjones@ezr:~$ echo "ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAw4DTU
RQ== jmjones@dink" > ~/.ssh/authorized_keys
jmjones@ezr:~$ ls -l ~/.ssh/
-rw-r--r-- 1 jmjones jmjones 400 2008-12-30 17:48 authorized_keys
After which, I am no longer prompted for a password to login. Here, I log out of the server, then ssh back in:
Connection to 192.168.1.20 closed.
dink:~ jmjones$ ssh 192.168.1.20
Last login: Tue Dec 30 17:50:26 2008 from dink
Notice that my ssh client didn't prompt me for a password. Now, anytime I want to connect to this server, I just ssh in and I will be instantly connected.
Executing Remote Commands
I mentioned earlier that after sshing to a remote server, you are dropped into a shell. This is the default behavior, but it isn't the only thing you can do. Another useful way of using an ssh client is to execute commands on a remote server without typing it into an interactive shell on the remote server. To state it another way, you can specify what command you want to run on the remote system when you execute the ssh utility on your local system. For example, if I wanted to see if a process is listening on port 25 on the remote system, I could do it like this:
dink:~ jmjones$ ssh 192.168.1.20 netstat -ltpn | grep 25
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN -
The syntax is "ssh address command." I could do the same thing to check disk usage, see which processes are running, or copy files around. And since I setup authorized_keys, it's not much more overhead to execute commands remotely than to execute them locally.
Why not just log in and run the commands interactively? Because you would lose the benefit of scriptability. Executing commands on a remote system can now become part of a shell script. And those shell scripts can run under cron. Now the possibilities for getting work done on remotes systems is an open horizon.
ssh is an essential tool. In its most common use, it allows you to interactively manipulate a shell on a remote server. This is certainly indispensable for remote system administration. It also lets you simplify and increase the security of the authentication process by using authorized keys. Finally, it allows you to execute shell commands on the remote system without being in the interactive shell.
Article courtesy of Enterprise IT Planet
Solid state disks (SSDs) made a splash in consumer technology, and now the technology has its eyes on the enterprise storage market. Download this eBook to see what SSDs can do for your infrastructure and review the pros and cons of this potentially game-changing storage technology.
- 1Linux Top 3: Ubuntu 14.04, Debian Gives Squeeze More Life and Red Hat Goes Atomic
- 2Linux Top 3: CoreOS, Oracle Enterprise Linux 7 and Ubuntu 14.10
- 3Linux Top 3: Debian Dumps SPARC, Ubuntu Takes Over Linux 3.13 and the Core Infrastructure Initiative
- 4Linux Top 3: Fedora, Ubuntu and Gluster Lose Community Leaders
- 5Red Hat Enterprise Linux 7 Finally Hits the Big Time