--On Friday, February 09, 2001 9:16 AM -0500 Pierre Abbat
<[EMAIL PROTECTED]> wrote:
> On Wed, 07 Feb 2001, Michael R. Jinks wrote:
>> Something else that can happen is that the server gets confused about
>> whether you really are connecting from "hostB" or "hostB.domain.com" or
>> "CNAME-for-hostB.domain.com" or some such. They aren't equivalent as
>> far as sshd is concerned. Maybe check the server-side logs for clues on
>> this, and then adjust the proper line in authorized_keys so that the
>> host name matches whatever your server thinks your client's name is.
>> I've also been known to cheat:
>>
>> 1024 35 1234reallylongrandomnumber5678 [EMAIL PROTECTED]
>> 1024 35 1234reallylongrandomnumber5678 mjinks@foo
>> 1024 35 1234reallylongrandomnumber5678 [EMAIL PROTECTED]
>>
>> That way no matter what the server gets for a reverse lookup (FQDN,
>> non-FQ-DN, or IP), you're covered.
>
> That would explain why I've had that problem. The problem is that I ssh
> to the remote host from a dialup, and I could get any of a dozen
> addresses. How can I tell the server to ignore the domain and just use
> the key that matches?
I'm unclear on what you're trying to do, and what sshd version you're
using. It looks like you're trying to do either RSA or DSA auth, or
RSARhosts auth.
If RSA or DSA auth:
- There shouldn't _be_ any client ip/fqdn checking. Michael R. Jinks'
comments seem to be mistaken. They certainly are for openssh. The last
field in authorized_keys is just an (optional) comment.
If RSARhosts:
- SSH is fundamentaly broken in the way it finds keys. It ties a key to a
hostname and/or IP address in ssh_known_hosts, and commits a layering
violation in the process. It should be transmitting a key identifier
in-band (pubkey, fingerprint, arbitrary identifier, whatever) and matching
based on the other party's claimed identity. I don't know if this is
fixable in V2 or not (one of these days I have to wade through the IETF
protocol docs).
--
Carson Gaspar - [EMAIL PROTECTED]
Queen trapped in a butch body
