Re: Fwd: Re: [cobalt-users] Fwd:ssh - problem - nearly there

[shimi <shimi@xxxxxxxxxxxxxxxx>]

On Sun, 15 Jul 2001, Gerald Young wrote:

> Hi Shimi,
> 	thanks for your quick answer.
> 
> >Fix what, asking for password? Do you want it to allow people to connect
> >without one? I don't understand. Maybe just.. uhm... enter the password?
> 
> ok i think im getting the hang of this I seem to be missing something simple I
> thought apart from the encryption side of things i could log on without having
> to send a password. ie i thought the server sent a challenge to my local ssh
> which it had to use the key to answer succesfully thus avoiding having to send
> a password after the first login.
> 
> Or is the whole point that the password is encrypted before being sent?
> 
indeed.
> 
> i am logging on as 
> ssh -l username www.servername
> 
> ok will try 
> ssh usename&servername.com
> 
> ssh servername no address associated with hostname
it's ssh username@servername, not &
so it looked up a machine named username&servername.com - which most likey
doesn't exist, as & are not allowed in domain names.
> 
> i agree with you i also have no idea what i am doing!!1
> off to do more reading
> b w gerald y
> 

you could do "man ssh" but i'll save u from that...

SSH2(1)                        SSH2                       SSH2(1)

NAME
       ssh2 - secure shell client (remote login program)

SYNOPSIS
       ssh2 [-l login_name] hostname [command]

bla bla bla

SSH protocol version 2

  When a user connects using the protocol version 2 different authentica
  tion methods are available: At first, the client attempts to authenticate
  using the public key method.  If this method fails password authentica
  tion is tried.

  The public key method is similar to RSA authentication described in the
  previous section except that the DSA or RSA algorithm is used instead.
  The client uses his private key $HOME/.ssh/id_dsa to sign the session
  identifier and sends the result to the server.  The server checks whether
  the matching public key is listed in $HOME/.ssh/authorized_keys2 and
  grants access if both the key is found and the signature is correct.
  The session identifier is derived from a shared Diffie-Hellman value and
  is only known to the client and the server.


  If public key authentication fails or is not available a password can be
  sent encrypted to the remote host for proving the user's identity.  This
  protocol 2 implementation does not yet support Kerberos or S/Key authen
  tication.

  Protocol 2 provides additional mechanisms for confidentiality (the traf
  fic is encrypted using 3DES, Blowfish, CAST128 or Arcfour) and integrity
  (hmac-md5, hmac-sha1).  Note that protocol 1 lacks a strong mechanism
  for ensuring the integrity of the connection.
  
Login session and remote execution

  When the user's identity has been accepted by the server, the server ei
  ther executes the given command, or logs into the machine and gives the
  user a normal shell on the remote machine.  All communication with the
  remote command or shell will be automatically encrypted.

  If a pseudo-terminal has been allocated (normal login session), the user
  can disconnect with ~., and suspend ssh with ~^Z. All forwarded connec
  tions can be listed with ~# and if the session blocks waiting for for
  warded X11 or TCP/IP connections to terminate, it can be backgrounded
  with ~& (this should not be used while the user shell is active, as it
  can cause the shell to hang).  All available escapes can be listed with
  ~?.

  A single tilde character can be sent as ~~ (or by following the tilde by
  a character other than those described above).  The escape character must
  always follow a newline to be interpreted as special.  The escape charac
  ter can be changed in configuration files or on the command line.

  If no pseudo tty has been allocated, the session is transparent and can
  be used to reliably transfer binary data.  On most systems, setting the
  escape character to ``none'' will also make the session transparent even
  if a tty is used.

  The session terminates when the command or shell on the remote machine
  exits and all X11 and TCP/IP connections have been closed.  The exit sta
  tus of the remote program is returned as the exit status of ssh.

Server authentication

  ssh automatically maintains and checks a database containing identifica
  tions for all hosts it has ever been used with.  RSA host keys are stored
  in $HOME/.ssh/known_hosts and host keys used in the protocol version 2
  are stored in $HOME/.ssh/known_hosts2 in the user's home directory.  Ad
  ditionally, the files /etc/ssh/ssh_known_hosts and
  /etc/ssh/ssh_known_hosts2 are automatically checked for known hosts.
  Any new hosts are automatically added to the user's file.  If a host's iden
  tification ever changes, ssh warns about this and disables password au
  thentication to prevent a trojan horse from getting the user's password.
  Another purpose of this mechanism is to prevent man-in-the-middle attacks
  which could otherwise be used to circumvent the encryption.  The
  StrictHostKeyChecking option (see below) can be used to prevent logins
  to machines whose host key is not known or has changed.



have fun,

- shimi.