ssh: Secure Shell
The ssh program suite is an interesting way to establish a secure communication channel between hosts across the Internet. It replaces a few usual communication channels (such as telnet, rlogin, rsh and rcp) and provides equivalent functionality via a new secure protocol. This article is meant to introduce the user to ssh features without any pretense of being an authoritative tutorial on security issues.
First of all, as usual with encryption material, let's throw in some legalese. The Unix implementation of the package is distributed free of charge for non-commercial use and can be retrieved from major ftp sites around the world. The meaning of “non-commercial use” is well stated in the COPYING file within the ssh distribution. Non-commercial use includes use of the tool by people who work on the Internet, provided ssh is not used as a selling argument. However, being allowed by the license is not enough to use the package. You must also ensure your government allows using cryptographic material: some countries prohibit citizens from using any type of cryptography.
As far as standardization is concerned, the IETF (Internet Engineering Task Force) is working on the ssh idea. This means that the protocol is going to be standardized and will always remain throughly documented. Anyone can reimplement the software and distribute her version with different copying policies. Although there is no RFC about ssh yet, three Internet drafts are already available which document the different aspects of the protocol. The drafts I downloaded in June are going to expire on September 1, 1997, but new drafts (or a real Request For Comments) will be released before that time.
The main aim of ssh is overcoming the security problems of TELNET and rsh-like protocols. These protocols, though widely used, are very weak as far as security is concerned: TELNET transmits clear-text passwords over the network, while rsh and friends are easily broken by spoofing techniques (skilled system administrators or anyone with physical access to the wire can exploit the .rhosts files to be granted access on remote computers). These vulnerabilities are addressed by the ssh protocol by enforcing a strong authentication scheme between the communicating parties.
The protocol not only authenticates the client host with the server, but also enforces encryption of all the data sent through the established communication channel. Although encryption requires some computational load in the communicating hosts, the user can be confident that no sniffer can make sense out of network packets, and nobody can forge packets to be granted access with the server.
Finally, the protocol is designed to allow encapsulation of other communication channels within an ssh stream, so that non-encrypted protocols can benefit from ssh capabilities at no cost. This feature is most useful for establishing secure X11 connections, but its use is much more flexible than just that security.
As far as the user interface is concerned, the new programs are designed as drop-in replacements for rsh, rlogin and rcp. While the system administrator needs to deal with the ssh issue at least to install the package, the final user can happily ignore the fact that the underlying communication mechanisms have been changed.
The current version of ssh, as I'm writing this article, is 1.2.20. It is distributed with a configure script, so that:
./configure && make && make install
does the complete job of installing the package. Even if /usr/local belongs to you, you'll need to be a privileged user in order to install ssh. This requirement is necessary, because both the server and some client programs must be able to open privileged TCP ports. Moreover, the package installs its system-wide files in the /etc directory. If you must run an ssh session without installing the programs as a privileged user, you should first read the FAQ file, which describes how to accomplish this without too much trouble.
The program suite is made up of a server program, a few clients and a pair of support tools. In order to become an ssh server, the suggested action is to invoke sshd from your initialization files when the computer boots. The program is installed by default in the /usr/local/sbin directory, and it listens to port 22/tcp of the local host to accept incoming connections. You should add a line like the following one to the /etc/services file, if it is not already included:
ssh 22/tcp # secure shell
It is possible to run sshd from /etc/inetd.conf, by passing the -i flag to the daemon. This practice is discouraged, because the daemon can take several seconds to start, as it generates an encryption key each time it starts.
On the client side, nothing needs to be done at installation time to enable use of the services. After installation, several programs can be found in the /usr/local/bin directory that can be executed by anyone. Here's a list of these programs:
ssh (slogin): The ssh client program behaves like rsh in that it executes a command on a remote host, redirecting its own stdin, stdout and stderr to the remote. If only one argument is specified in the command line, it is taken as the remote host, and ssh opens a terminal session on that host, just as rlogin does. The slogin client is just a symbolic link to ssh. Usually, the user is asked to provide a password for authentication on the remote host.
scp: “Secure CoPy” is a replacement for “Remote CoPy”. It uses the same syntax and performs the same task, with the same security enhancements offered by ssh. The user is usually prompted for a password to perform authentication.
ssh-keygen: This program generates new keys associated to the user who invokes it. The public key and the private key generated are saved by default in the directory $HOME/.ssh/, in two files called identity and identity.pub. A pair of keys is needed, when you wish to securely log into the local host from outside without providing a password.
ssh-agent: This program is meant to manage security for a user session. It stores the private keys for the user and can be contacted by any child process. See the man page for more information about ssh-agent.
ssh-add: This program adds identities to the authentication agent. ssh-agent must be an ancestor of the process running ssh-add in order for them to communicate.
ssh-askpass: This short program is used internally by ssh-add and ssh-keygen to ask for a pass phrase using the X graphical environment.
make-ssh-known-hosts: This PEl script retrieves the public keys of all hosts in a domain; it queries the DNS and talks with hosts belonging to a domain. This program updates the /etc/ssh_known_hosts file to hold the new keys. The program should be run periodically, usually via cron, to reflect any change in host public keys or new installations of ssh on hosts in the local networks.
Although the number of installed files might scare a novice user, there's nothing new to learn as long as you just use the plain ssh and scp client programs. The system administrator can even choose to replace ssh for rsh and scp for rcp, so that secure operation is completely transparent to the final user. Actually, such a replacement is not completely transparent, since ssh introduces a new feature not present in plain rsh or rlogin: X11 forwarding. This feature is considered a “side effect”of using the ssh protocol and is described in the next section.
The role of the other programs is secondary. They help to set up a good working environment to avoid typing too many passwords during normal operation without compromising system security. While knowing their internals is not essential for program operation, a quick look over the documentation might provide interesting insights about current encryption technology and can help in configuring hosts to automate the login process.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Tech Tip: Really Simple HTTP Server with Python
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide