Women in Technology

Hear us Roar



Article:
  SSH on Mac OS X for Worry-Free Wireless
Subject:   SSH Problem with Instructions
Date:   2001-11-22 08:21:08
From:   cochella
Great article; clear concise.


However, I am unable to repeat the SSH public/private key login process.


I following the instructions exactly and was always prompted for a password and not a passphrase (I chose to provide a passphrase).


The closest I can get to being prompted for a passphrase (I also get prompted for a password after entering the passphrase) is to do a few changes:


1. On the remote host put the public id_dsa.pub key in .ssh2/ and create a file called "authorization" that contains "Key id_dsa.pub". This is for multiple keys I believe.


2. Edit the id_dsa.pub key on local and remote to remove "ssh-dss" at the beginning of the key file and the "username@localhost" at the end of the key file.


After doing all of this I still get the following session:


ssh -l chris hostname.com
Enter passphrase for key '/Users/cochella/.ssh/identity':
chris@hostname.com's password:
Last login: Thu Nov 22 09:28:36 2001 from 166.70.174.201
[chris@server1 cochella]$



If I understand everything this means that passphrase encryption (based on the keys) did not take place and a lesser form of encryption via the password was executed. Is this correct?


How can I fix this?


I have been forward and backward with all possible combinations and verifying passwords.


Thank you,


Chris


Local System: Mac OSX 10.1
Remote System: RedHat 6.2 running openssh

Main Topics Oldest First

Showing messages 1 through 1 of 1.

  • SSH Problem with Instructions
    2001-11-26 19:22:35  res [View]


    1. On the remote host put the public id_dsa.pub key in .ssh2/ and create
    a file called "authorization" that contains "Key id_dsa.pub". This is for
    multiple keys I believe.


    No; this is the convention used by the SSH server from HREF="http://www.ssh.com/">ssh.com. It will not work with OpenSSH
    (which is what you say is running on the server). And if the server
    were ssh.com, you would need to convert the key format in any
    case.


    2. Edit the id_dsa.pub key on local and remote to remove "ssh-dss" at the
    beginning of the key file and the "username@localhost" at the end of the
    key file.


    The "username@localhost" is a comment and removing it does no harm, but
    the leading "ssh-dss" is part of the key format, and removing it will
    break the file.


    After doing all of this I still get the following session:
    ssh -l chris hostname.com
    Enter passphrase for key '/Users/cochella/.ssh/identity':
    chris@hostname.com's password:
    Last login: Thu Nov 22 09:28:36 2001 from 166.70.174.201
    [chris@server1 cochella]$

    If I understand everything this means that passphrase encryption (based on
    the keys) did not take place and a lesser form of encryption via the
    password was executed. Is this correct?


    There are a couple bits of confusion here.



    1. The name of the key file implies that the connection is using SSH
      protocol version 1 (you can see this more specifically using ssh -v
      ...
      . The key you generated can only be used with protocol 2, so
      public-key authentication will not work. Even if the server supports
      protocol 2, the version of OpenSSH which comes with OSX (2.3.0) will choose
      protocol 1 if it's available (this default was changed in OpenSSH-2.9).
      Try ssh -2 ....

    2. The client authentication method you employ has no bearing on what
      kind of encryption protects the session. All session encryption
      parameters are in fact negotiated and put into use before client
      authentication even takes place.




    +-----------------------------------------------------------------------------+
    | Richard Silverman | co-author: SSH, The Secure Shell (The Definitive Guide) |
    | slade@shore.net | O'Reilly, 2001 -- http://www.oreilly.com/catalog/sshtdg |
    +-----------------------------------------------------------------------------+