Network Security Consulting Agency Since 1989 - Specialized in Unix, Windows, TCP/IP and Internet
Text mode: access to the page content
Hervé Schauer Consultants
You are here: Home > Resources > Tips > Revisite de la configuration du client OpenSSH
Go to: HSC Trainings
Version française
o Skills & Expertise
o Consulting
o ISO 27001 services
o Audit & Assessment
o Penetration tests
o Vunerability assessment (TSAR)
o Forensics
o Training courses
o E-learning
o Agenda
o Past events
o Tutorials
o Thematic index
o Tips
o Lectures
o Courses
o Articles
o Tools (download)
o Vulnerability watch
o Hervé Schauer
o Team
o Job opportunities
o Credentials
o History
o Partnerships
o Associations
   Press and
o HSC Newsletter
o Bulletin juridique HSC
o Press review
o Press releases
o Publications
o How to reach us
o Specific inquiries
o Directions to our office
o Hotels near our office
|>|Revisite de la configuration du client OpenSSH  

by Nicolas Collignon et Louis Nyffenegger (21/08/07)

---[ OpenSSH client for ease, fun and ... profit ]----------------------------

Cet article est disponible en français à ssh_config.html.fr .

--[ 1. Introduction ]---------------------------------------------------------

This article is a reminder about OpenSSH client configuration. It also exposes
some tips which can make life easy with OpenSSH.

Users specific configurations are stored in the home directory (~/.ssh/config)
and the global configuration is located in /etc/ssh/ssh_config.

--[ 2. Configuration file ]---------------------------------------------------

In the configuration file, settings can be set per host or for all hosts.

For example, compression can be enabled for all hosts:

or hostnames can be hashed before their storage ((in the know_hosts file):
	HashKnownHosts yes

Enabled this setting for each host is useless because ssh will not hashed
the hash before storage.

The configuration per host is realized by using the Host keyword follow by
all settings :

For example, for the host wwww.hsc.fr, the configuration may been:
	Host www.hsc.fr
		User user

Selon la configuration DNS, il est intéressant de mettre sur la même ligne
tous les noms correspondant à la même machine :
	Host www www.hsc.fr

On voit ici une option très pratique permettant de spécifier le nom de
l'utilisateur sur la machine distante, ainsi il ne sera plus nécessaire
d'utiliser "ssh user@www.hsc.fr" ou "ssh www.hsc.fr -l user" mais uniquement
"ssh www.hsc.fr" même si le nom d'utilisateur local diffère du nom
d'utilisateur distant.

Some options can be usefull, like :

	- BatchMode (default no) which forced ssh to not ask for a password
	(if BatchMode equals yes), it can be used for scripts or batchs.

	- IdentityFile to set the identity storage file (private key file).

	- LocalCommand (only if PermitLocalCommand yes is set, default is no)
	run the specified command on localhost when the connection is

	- ProxyCommand pour spécifier la commande à éxecuter pour se
	connecter au serveur, par exemple nc, les wildcard %h et %p
	respectivement pour la machine et le port distant sont disponibles.

--[ 3. SSH connections multiplexing ]-----------------------------------------

The local socket used by SSH clients to multiplex all connections may be
stored in a private folder (i.e: home folder) or in a public
folder (i.e: /tmp).

--[ 4. "ControlMaster auto" vs. ssh-agent ]-----------------------------------

--[ 5. Authentication's duration reduction ]---------------------------------

Reduce earth's global warming and save few bytes of network traffic :)

Authentication processus requires a varying amount of packets to be exchanged
between the SSH client and the SSH server. This variation is mostly due to the
fact that all servers don't require the same authentification method.
Preferred authentication methods may be changed in the configuration file
with parameter "PreferredAuthentications". Valid values regarding SSH protocol
version 2 are generally :

  - publickey
  - keyboard-interactive
  - hostbased

There is a typical case where authentication process may be shorten : the
OpenSSH client tries to authenticate with the RSA and DSA keys of a user
even if we would like to authenticate with a password. This can be true only
if the user have a valid RSA and DSA keys but it's often the case.

debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/admin/.ssh/id_rsa
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Offering public key: /home/admin/.ssh/id_dsa
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: keyboard-interactive

i.e: To connect faster using a password, one can use this configuration :

	Host machine1
		PreferredAuthentications keyboard-interactive

By using this configuration, OpenSSH client won't try to use the keys wich
are locally valid but not registred on the server side.

debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: keyboard-interactive

2 SSH requests which means 4 TCP messages so few bytes and milliseconds saved.

--[ 6. TCP Ports forwarding ]-------------------------------------------------

TCP ports redirection is often useful when outgoing ports are restricted in
corporate networks. But it becomes a little complicated when playing with
multiple ports forwarding dealing with hosts only available throurg a
forwarded port.

Chaining port forwarding may be automatized. Let's say we have 2 servers
waiting for connections on port 22/tcp. The administrator would like to
forward one of the server through the SSH server of the other.

    	-----	      -----	    -----
       |     |       |     |	   |	 |
       |     |       |     |	22 |	 |
       |     |=======|     |-------|	 |
       |     |       |     |	   |	 |
       |_____|       |_____|	   |_____|

        admin        server1       server2

The following configuration file will do the forwarding work for us :

	Host server1
		User admin
		ControlMaster auto
		ControlPath ~/.ssh/socket1-%r@%h:%p
		LocalForward=2022 server2:22

	Host server2
		User admin
		ControlMaster auto
		ControlPath ~/.ssh/socket2-%r@%h:%p
		HostKeyAlias server2

With such configuration once we connect to server1, port 2022 is forwarded
to server2's SSH server.

"HostKeyAlias" option is important because it solves the problem of having
multiple entries in file ~/.ssh/know_hosts with the same hostname (localhost
in the case).

--[ 7. Conclusion ]-----------------------------------------------------------

Maybe you learnt one or two tips, maybe you didn't. Anyway a nicely configured
OpenSSH client can do many things which simplify SSH every day uses.

                    -- Nicolas Collignon <Nicolas.Collignon@hsc.fr> --
                    -- Louis Nyffenegger <Louis.Nyffenegger@hsc.fr> --

--[ 8. References ]-----------------------------------------------------------

 - OpenSSH Web site:

 - "SSH et la redirection X11" (fr) - Franck Davy

 - "Administration distante de systèmes Windows (Partie 1) - SSH" (fr)
                                              - Jean-Baptiste Marchand

 - "Installation d'OpenSSH sous Solaris" (fr) - Thomas Seyrat

 - "chrooter un compte avec OpenSSH" (fr) - Denis Ducamp

Last modified on 27 September 2007 at 16:12:29 CET - webmaster@hsc.fr
Information on this server - © 1989-2013 Hervé Schauer Consultants