HSC
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
Télécharger le catalogue des formations
Search:  
Version française
   Services   
o Skills & Expertise
o Consulting
o ISO 27001 services
o Audit & Assessment
o Penetration tests
o Vunerability assessment (TSAR)
o Forensics
o ARJEL
o Training courses
o E-learning
   Conferences   
o Agenda
o Past events
o Tutorials
   Resources   
o Thematic index
o Tips
o Lectures
o Courses
o Articles
o Tools (download)
o Vulnerability watch
   Company   
o Hervé Schauer
o Team
o Job opportunities
o Credentials
o History
o Partnerships
o Associations
   Press and
 communication
 
 
o HSC Newsletter
o Bulletin juridique HSC
o Press review
o Press releases
o Publications
   Contacts   
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:
	Compression=yes

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
	established.

	- 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
		Hostname=localhost
		Port=2022
		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:
   http://www.openssh.org

 - "SSH et la redirection X11" (fr) - Franck Davy
   http://www.hsc.fr/ressources/breves/ssh-x11.html

 - "Administration distante de systèmes Windows (Partie 1) - SSH" (fr)
                                              - Jean-Baptiste Marchand
   http://www.hsc.fr/ressources/breves/remote_windows_ssh.html

 - "Installation d'OpenSSH sous Solaris" (fr) - Thomas Seyrat
   http://www.hsc.fr/ressources/breves/ssh-solaris.html

 - "chrooter un compte avec OpenSSH" (fr) - Denis Ducamp
   http://www.hsc.fr/ressources/breves/chroot-openssh.html




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