ssh-ecurity — Part 2: In command with ssh.
In "ssh-security — Part 1: What is ssh?", I introduced the basic ssh command as a way to log into a remote host maintaining a secure encrypted channel between the local and remote. However, ssh is so much more than just a replacement for telnet or its OpenVMS DECnet equivalent$ SET HOST with encryption. It's chock full of features which make ssh a very powerful tool; even if you don't use it as a command line tool. These will be explored as this series progresses; however, let's first take a look at some of the ssh features from the command line for those that use the command line.
Those familiar with unix may know the unix rsh (remote shel) command. This command allows a user on the local system to execute a command on the remote system. The problem with this command is that remote system login information (username and password) must be supplied for the command to exercise commends on the remote and this information was sent in plain text to the remote. Sending any system authentication information in plain text over the internet is not an ideal thing to do. I always say, "just because I am paranoid doesn't mean that they're not out to get me!"
Your authentication pair (ie. username and password) are the basics for identifying that you are you to a system or an application. Therefore, it's important that you protect your identity. In a day and age where identity theft is so prevalent, it only makes sense to protect this information and it's so simple to do.
ssh to the rescue!
That's right, with ssh you also get an rsh-like capability. Commands can be executed on a remote system simply by post-fixing the command to be executed to the ssh command after the username@host portion of the command.
In the OpenVMS world, there was no direct equivalent to rsh. You would either have to use a DECnet task written and stored on the remote, and you needed to have access to it or, you could use:
$ MCR SYSMAN
SYSMAN> SET ENVIRONMENT/NODE=(remotenodename)
SYSMAN> DO command-to-be-executed
SYSMAN has certain advantages over the unix rsh but for simple commands, it's not the ideal tool for the occasional remote command. In addition, as I will point out in a subsequent blog, it requires the transmission of user authentication information to the remote node if that node does not have a proxy for the user. The same can be said for the remote DECnet task approach.
So, since this blog is about ssh, let's see how this works with it.
Suppose you want to check on the uptime of servers for which you are responsible. You could log into each and then issue the appropriate command to examine the system's uptime. However, with ssh, you can do this in one operation from the local system.
$ ssh myusername@myvms.mydomain.com SHOW SYSTEM/NOPROCESSES
myusername's password:
OpenVMS V7.3-2 on node MYVMS 28-JUL-2009 16:59:34.03 Uptime 552 02:54:46
$ ssh myusername@mylinux.mydomain.com uptime
myusername's password:
17:02:24 up 9 days, 7:57, 4 users, load average: 0.28, 0.25, 0.2
Note that the remote system account's username and password must still be provided but it is sent encrypted to the remote. The identity is protected from unwanted nefarious prying eye.
Frontpage
