The 101 Uses of OpenSSH: Part I

 in
Mick scratches the surface of ssh.
SSH for the Masses: Doing the “Encrypted Telnet” Thing

What if all you need are interactive shell sessions on remote systems à la Telnet? Chances are that even without so much as looking at a configuration file, you need to simply enter:

ssh remote.host.net

You will be prompted for a password (ssh will assume you wish to use the same user name on the remote system as the one you're currently logged in with locally), and if that succeeds, you're in! That's arguably simpler and indisputably much more secure than Telnet.

If you need to use a different user name on the remote system than the one you're logged in with locally, you need to add the flag -l followed by your remote username. For example, if I'm logged on to my laptop as “mick” and wish to ssh to kong-fu.mutantmonkeys.org as user “mbauer”, I'll use the command:

ssh -l mbauer kong-fu.mutantmonkeys.org

What is this doing for me? Nothing seems much different from Telnet. I may be asked whether to accept the remote server's public key, it may take somewhat longer for the session to get started and depending on network conditions, server load, etc., the session may seem slightly slower than Telnet, but for the most part I won't notice much difference.

But I will have logged in without sending my username and password over the network in clear text, and all session data will be encrypted as well. I can do whatever I need to do, including su -, without worrying about eavesdroppers. And all it costs me is a tiny bit of latency!

Digging into Configuration Files

Configuring OpenSSH isn't complicated either. To control the behavior of the ssh client and server there are only two files to edit: ssh_config and sshd_config. Depending on the package you installed or the build you created, these files are either in /etc or some other place you specified using .configure's -sysconfdir directory.

ssh_config is a global configuration file for ssh client sessions initiated from the local host. Its settings are overridden by command-line options and by users' individual configuration files (kept, if they exist, in $HOME/.ssh/config). For example, if /etc/ssh/ssh_config contains the line:

Compression no

but the file /home/bobo/.ssh/config contains the line

Compression yes
then whenever the user “bobo” initiates a ssh session, compression will be enabled by default, even though for users without this setting in their own $HOME/.ssh/config files compression will be turned off. If, on the other hand, bobo invokes ssh with the command:
ssh -o Compression=no remote.host.net
then compression will not be enabled for that session.

In other words, the order of precedence for ssh options is, in decreasing order, the ssh command-line invocation, $HOME/.ssh/config, and /etc/ssh/ssh_config.

ssh_config consists of a list of parameters, one line per parameter, in the format:

parameter value(s)

Some parameters are Boolean and can have a value of either “yes” or “no”. Others can have a list of values separated by commas. Most parameters are self-explanatory, and all are explained in the ssh(1) man page. Table 1 shows a few of the most useful and/or important ones (italicized text indicates possible values).

Table 1. Some Basic Client Options for ssh_config

There are many other options in addition to these; some of them will be covered in Part II of this article. Refer to the ssh man page for a complete list.

Configuring and Running sshd, the Secure Shell Dæmon

All of that's fine if the hosts you connect to are administered by other people. But we haven't yet talked about configuring your own host to accept ssh connections. As it happens, this is very simple.

As with the ssh client, sshd's default behavior is configured in a single file, “sshd_config” that resides either in /etc or wherever else you specified the ssh's configuration directory. And as with the ssh client, settings in its configuration file are overridden by command-line arguments. Unlike the ssh client, however, there are no configuration files for the dæmon in individual users' home directories; ordinary users can't dictate how the dæmon behaves.

Table 2 describes a few of the things that can be set in sshd_config.

Table 2. Setting Parameters in sshd_config

There are many other parameters that can be set in sshd_config. We'll cover some of those next month, but understanding the above is enough to get started (assuming your immediate need is to replace Telnet and ftp).

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

thanks

joviton's picture

god bless you for taking trouble in writing this tutorial of SSH .
linux is the best OS ever .

Linux

Misafir's picture

Linux Where the on World Wide should look

Using SSH

Mithilesh's picture

Hi,

I am new and today used the SSH first time then i thought to study more about SSH and googled the uses of SSH and found your website its very helpfull but still i am unable to understand few things can yu suggest me any good site/article for a new user. I wanted to use this just because it is fast and i love it.

about ssh

Rakesh's picture

sir
I read your article The 101 Uses of OpenSSH: Part I
it boost me to start doing experiments with ssh. it gives me all the basic as i am new bie to it.
But I had one problem i tried to uninstall ssh from my system to install new one using rpm -e option -> It not worked.
I knew (through net searching)the new intallation overwrite the old one, but i want to remove it and install it on my system(redhat-9).
Please can you suggest anything regarding this.

thanking you.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState