Re: Trouble with OpenSSH... SOLVED!!!

From: Bill Barnett (spam.me.not_at_fuse.net)
Date: 02/11/04 

Date: 11 Feb 2004 12:25:44 -0800

Hello all,

It turns out that running the server in debug mode uncovered the
issue. (Due to the fact that I am not the sysadmin of the server and
the fact that the sysadmin of the server was not the sysadmin of the
corporate firewall plus the fact that the sysadmin of the server could
not take down the ssh server to permit debugging this was not an easy
task!)

We ran a separate server on port another port and determined the issue
to be one of directory permissions which must be 755 for the user and
.ssh directories (my problem was that this particular user's home
directory was 775) and either 600 or 644 for any file within the .ssh
directory.

Special thanks to Mike for his assistance with this matter.

Thanks to all,

Bill

Mike <mike@nomail.com> wrote in message news:<4020e15e@funnel.arach.net.au>...
> William Barnett wrote:
> > Hello Mike,
> >
> > On Tue, 03 Feb 2004 17:27:51 +0800, Mike wrote:
> >
> >
> >>William Barnett wrote:
> >><SNIP>
> >>
> >>>>If you run the server in debug mode, you will most likely find your answer.
> >>>>
> >>>>On another point, passwords are never exchanged in plain text using SSH.
> >>>> There is nothing particularly unsafe about using password
> >>>>authentication, so long as you stick to good practices like changing
> >>>>your "non trivial" password regularly. You are afforded a little more
> >>>>security using pub/priv keys by the fact that an attacker would need to
> >>>>key log you AND steal your private key file. If you are really worried,
> >>>>you might like to use one time passwords. It is a balance of how much
> >>>>inconvenience you are prepared to put up with versus how likely it is
> >>>>that anybody would expend that much effort to hack your PC.
> >>>>
> >>>>You should upgrade your OpenSSH to the latest 3.7x something. I was
> >>>>never able to find decent rpms for anything past 3.4, so you may be
> >>>>resigned to downloading the source and compiling.
> >>>>
> >>>>Mike
> >>>
> >>>
> >>>I am experiencing a similar problem using passkey authentication with the
> >>>twist that a particular user can connect successfully using passkey
> >>>authentication while another particular user skips passkey for password
> >>>authenication which then completes successfully. No special command line
> >>>parameters are used by either user, e.g., ssh <user>@<host> and both are
> >>>connecting from the same client to the same server. This leads me to
> >>>remove the client's ssh_config and server's sshd_config files from
> >>>suspicion. Neither user has created a ~/.ssh/config file. I have checked
> >>>permissions in both user's directories at both ends of the connection and
> >>>all appear to be set identically. I have output debug info from both
> >>>connection attempts into text files and diff'ed the two but am unfamiliar
> >>>enough with ssh to gain anything meaningful to me. Perhaps someone else
> >>>will spot the issue. I have copied the diff text below.
> >>>
> >>>Thanks for your time and attention,
> >>>
> >>>Bill
> >>>
> >>>
> >>
> >><SNIP>
> >>
> >>Perhaps if you just included the debug from the one that did not work.
> >>The diff'd output was ?????
> >
> >
> > The diff'ed output was my attempt to meant to highlight exactly where the
> > successful and unsuccessful attempts diverged. Obviously those lines that
> > varied only in path were of no significance. Here is the unadulterated
> > debug output from the failed passkey authentication attempt which I killed
> > once prompted for a password rather than a passphrase:
>
> <SNIP see previous post for complete debug>
>
>
> > debug1: Offering public key: /home/cvsadm/.ssh/id_rsa
> > debug3: send_pubkey_test
> > debug2: we sent a publickey packet, wait for reply
> > debug1: Authentications that can continue: publickey,password,keyboard-interactive
>
>
> The answer must lie somewhere in the server, as the client is sending
> the key successfully. I may sound like a silly question, but are you
> absolutely sure that the public and private pair match? Have you tried
> running the server in debug mode? The debug output will tell you why
> the server is not accepting the key. I have sometimes copied known
> working key pairs into directories in order to exclude the mis-matched
> key possibility.
>
>
> > I bought the O'Reilly SSH guide last night and will be pouring over it
> > today or for at least as long as it takes to resolve this issue.
> >
> > Thanks for your time and assistance,
> >
> > Bill
>
>
> I have not read the book, but it sounds like a good idea. It may well
> save you from any more frustrating events.
>
> Mike