j'ai fais un man sshd, et voila ce que ca me donne.... 
SHD(8) BSD System Manager's Manual SSHD(8)
NAME
sshd - OpenSSH SSH daemon
SYNOPSIS
sshd [-deiqtD46] [-b bits] [-f config_file] [-g login_grace_time]
[-h host_key_file] [-k key_gen_time] [-o option] [-p port] [-u len]
DESCRIPTION
sshd (SSH Daemon) is the daemon program for ssh(1). Together these pro-
grams replace rlogin and rsh, and provide secure encrypted communications
between two untrusted hosts over an insecure network. The programs are
intended to be as easy to install and use as possible.
sshd is the daemon that listens for connections from clients. It is nor-
mally started at boot from /etc/rc. It forks a new daemon for each
incoming connection. The forked daemons handle key exchange, encryption,
authentication, command execution, and data exchange. This implementa-
tion of sshd supports both SSH protocol version 1 and 2 simultaneously.
sshd works as follows.
SSH protocol version 1
Each host has a host-specific RSA key (normally 1024 bits) used to iden-
tify the host. Additionally, when the daemon starts, it generates a
server RSA key (normally 768 bits). This key is normally regenerated
every hour if it has been used, and is never stored on disk.
Whenever a client connects the daemon responds with its public host and
server keys. The client compares the RSA host key against its own
database to verify that it has not changed. The client then generates a
256 bit random number. It encrypts this random number using both the
host key and the server key, and sends the encrypted number to the
server. Both sides then use this random number as a session key which is
used to encrypt all further communications in the session. The rest of
the session is encrypted using a conventional cipher, currently Blowfish
or 3DES, with 3DES being used by default. The client selects the encryp-
tion algorithm to use from those offered by the server.
Next, the server and the client enter an authentication dialog. The
client tries to authenticate itself using .rhosts authentication, .rhosts
authentication combined with RSA host authentication, RSA challenge-
response authentication, or password based authentication.
Rhosts authentication is normally disabled because it is fundamentally
insecure, but can be enabled in the server configuration file if desired.
System security is not improved unless rshd, rlogind, and rexecd are dis-
abled (thus completely disabling rlogin and rsh into the machine).
SSH protocol version 2
Version 2 works similarly: Each host has a host-specific key (RSA or DSA)
used to identify the host. However, when the daemon starts, it does not
generate a server key. Forward security is provided through a Diffie-
Hellman key agreement. This key agreement results in a shared session
key.
The rest of the session is encrypted using a symmetric cipher, currently
128 bit AES, Blowfish, 3DES, CAST128, Arcfour, 192 bit AES, or 256 bit
AES. The client selects the encryption algorithm to use from those
offered by the server. Additionally, session integrity is provided
through a cryptographic message authentication code (hmac-sha1 or hmac-
md5).
Protocol version 2 provides a public key based user (PubkeyAuthentica-
tion) or client host (HostbasedAuthentication) authentication method,
conventional password authentication and challenge response based meth-
ods.
Command execution and data forwarding
If the client successfully authenticates itself, a dialog for preparing
the session is entered. At this time the client may request things like
allocating a pseudo-tty, forwarding X11 connections, forwarding TCP/IP
connections, or forwarding the authentication agent connection over the
secure channel.
Finally, the client either requests a shell or execution of a command.
The sides then enter session mode. In this mode, either side may send
data at any time, and such data is forwarded to/from the shell or command
on the server side, and the user terminal in the client side.
When the user program terminates and all forwarded X11 and other connec-
tions have been closed, the server sends command exit status to the
client, and both sides exit.
sshd can be configured using command-line options or a configuration
file. Command-line options override values specified in the configura-
tion file.
sshd rereads its configuration file when it receives a hangup signal,
SIGHUP, by executing itself with the name it was started as, i.e.,
/usr/sbin/sshd.
The options are as follows:
-b bits
Specifies the number of bits in the ephemeral protocol version 1
server key (default 768).
-d Debug mode. The server sends verbose debug output to the system
log, and does not put itself in the background. The server also
will not fork and will only process one connection. This option
is only intended for debugging for the server. Multiple -d
options increase the debugging level. Maximum is 3.
-e When this option is specified, sshd will send the output to the
standard error instead of the system log.
-f configuration_file
Specifies the name of the configuration file. The default is
/etc/ssh/sshd_config. sshd refuses to start if there is no con-
figuration file.
-g login_grace_time
Gives the grace time for clients to authenticate themselves
(default 120 seconds). If the client fails to authenticate the
user within this many seconds, the server disconnects and exits. ..........
enfin, en gros, il doit y avoir une centaine de pages.... 
, webdav c'est un protocole fait exprès