ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button
Article:
  SSH on Mac OS X for Worry-Free Wireless
Subject:   SSH Problem with Instructions
Date:   2001-11-26 19:22:35
From:   res
Response to: SSH Problem with Instructions


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 |
+-----------------------------------------------------------------------------+


1 to 1 of 1
  1. SSH Problem with Instructions
    2001-11-28 13:58:11  cochella [View]

1 to 1 of 1