OSX (OpenSSH) to GNU (SSH2) server authentication problems
From: Mark Moorcroft (list@valleyofspeed.com)Date: 12/31/01
- Next message: Joonas Saarinen: "Re: SSH doesn't work without a user logged in?"
- Previous message: Bill K.: "Re: ssh without password"
- In reply to: Richard E. Silverman: "Re: F-Secure client with OpenSSH server"
- Next in thread: Bill Unruh: "Re: F-Secure client with OpenSSH server"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: list@valleyofspeed.com (Mark Moorcroft) Date: 31 Dec 2001 10:44:52 -0800
slade@shore.net (Richard E. Silverman) wrote in message news:<m1ly9jkq9zv.fsf@syrinx.oankali.net>...
>
> The problem you're having is different than the one we've discussed in
> this thread. Your difficulty is with server authentication, whereas we
> were discussing user authentication.
Agreed, but I felt the subject still applied, and thank you for
responding.
>
> This indicates that you already have a hostkey for your OSX box on the
> client host, and it is incorrect; you need to replace it (in the file
> indicated) with the current one.
I have done so many, many times with the same result. Both by file
transfer and copy/paste methods.
> Use the OpenSSH ssh-keygen to convert
> your OSX box's public hostkey and use that.
I did that also. It's not clear to me why OSX keygen creates the
public and private keys in different formats?
> If you have multiple
> hostkeys,
No, I simplified things as much as possible to troubleshoot.
> you need to select the one that SSH2 normally uses;
> unfortunately, the ssh.com software does not allow for multiple keys in
> its known-hosts list.
>
> > The authenticity of host 'pluto.he.net (xxx.xxx.xxx.xxx)' can't be
> > established.
> > DSA key fingerprint is
> > c6:f1:fb:b6:88:67:a2:b8:a5:a7:a4:29:ef:xx:xx:xx.
> > Are you sure you want to continue connecting (yes/no)? no
> > Aborted by user!
>
> This simply means that you have no hostkey entry at all on your OSX box
> for the he.net server -- get its public hostkeys and place entries for
> them in your personal or global known-hosts lists (~/.ssh/known_hosts or /etc/ssh_known_hosts).
Would that be known_hosts2 ?? I had already done that many times also.
One of my problems has been that Hurricane has man pages for a
different version of ssh than is installed on their box. For instance,
there is no mention of a .ssh2 directory anywhere in the man pages,
but that is what their ssh-keygen creates.
Anyway I have some developments. I started testing with my OSX box at
work last night. Using the same procedures I had been using at home
for key generation and etc. I was able to get publickey authentication
going. The wierd part is that my home OSX box still won't play. In
order to get the work box going I tweaked a few settings, and I'm
ashamed to admit that I lost track of exactly what :-( However, the
debug for the home box attempts now report that it is giving up on the
pubkey method. I "diff'd" the ssh_config and sshd_config on the two
boxes to verify that they are the same. The question that remains
unanswered is what differs them. So far the only thing I can identify
is the permissions in and around the home directory. I can verify that
they are stricter on the box that fails, but I'm not sure how they got
that way, or if that's the problem.
debug1: authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,password,keyboard-interactive
debug3: authmethod_lookup publickey
debug3: remaining preferred: password,keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: next auth method to try is publickey
debug1: try privkey: /Users/mark/.ssh/id_rsa
debug3: no such identity: /Users/mark/.ssh/id_rsa
debug1: try pubkey: /Users/mark/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: keyboard-interactive
debug3: authmethod_is_enabled password
debug1: next auth method to try is password
- Next message: Joonas Saarinen: "Re: SSH doesn't work without a user logged in?"
- Previous message: Bill K.: "Re: ssh without password"
- In reply to: Richard E. Silverman: "Re: F-Secure client with OpenSSH server"
- Next in thread: Bill Unruh: "Re: F-Secure client with OpenSSH server"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
