Re: Weird ssh problem
> Thanks for your help Heather, but it was a network problem at my provider. Everything
> works now without a change in my config.
Ahh! Good to hear that you figured it out.
> But it was still weird that 1 remote user didn't work, and the others did.
>
> > On Sun, Jun 16, 2002 at 06:35:55PM +0200, Jo Geraerts wrote:
> > oh, that's not so good, mine says
> > debug1: identity file /home/heather/.ssh/identity type 0
> > debug1: identity file /home/heather/.ssh/id_rsa type 1
> > debug1: identity file /home/heather/.ssh/id_dsa type -1
> > So I'd interpret that as saying you don't have any keys as far as it's
> > concerned.
>
> I deleted them so i could test if they weren't currupted. But if i ssh to root@host1
> as the same local user, it worked. In that case the ssh client didn't find the
> keys either, but the remote host asked for the password.
>
> > > debug1: Found key in /home/ernie/.ssh/known_hosts:1
> > This being why on your side. If you're on testing, this means it's
> > using ssh 1 protocol, I think... a type 2 would have been found in
> > known_hosts2 (rsa or dsa).
>
> i think the :1 stands for the x'th key in know_hosts, so it's the first key that matches
> the remote host.
> > > Connection closed by 213.119.61.223
> > However the distant server isn't configured to try that. No key, no
> > donut.
> > > debug1: Calling cleanup 0x80633cc(0x0)
> > ... so it hangs up.
>
> It hangs up after a loooong timeout ( 10 minutes or so). So i think it was
> expecting some packets.
>
> > > At this point one should think there is something wrong with the user jgeraert.
> > > But when i ssh from another server (i used the server at school)
> > > ssh jgeraert@host1 works just fine like it should.
> >
> > Good, but that suggests that it's not permissions in jgervert@host1's
> > .ssh account. The other users on the same site working means that you
> > don't have too deeply broken an sshd setup (the daemon on host1). So
> > it's down to permissions in your CLIENT-side .ssh directory, and whether
> > or not you have a key.
>
> It couldn't be the client side permissions either, because with the same
> local user i could ssh' to root@host1 and tester@host1.
If all your permissions are wrong, you still get allowed to use
'password' style ... if the remote server is willing, of course. So the
fact that it worked when you went to root@host1, by way of demanding
your password rather than accepting a key, does -not- exonerate the
permissions of your client side .ssh area.
However, your net provider toasting part of the conversation, would
easily lead to it acting one way sometimes, and differently other times.
> > > tcp 0 28 adsl-96904.turbol:33097 D5773DDF.kabel.tel:2223 ESTABLISHED
> > Isn't it normal to have some packets-in-flight on a connection which is
> > expected to be a session?
>
> yes but in when i looked multiple times, the send-q value didn't change. I don't
> think there are always the same amount of packets in flight.
The conversation type is fundamentally the same, and you haven't changed
kernels so you haven't changed TCP stack. Why couldn't it be the same
number of packets?
Now, once you had actually established the link.... then your own actiities would
be different all the time, and it would get suitably unpredictable.
> But now everything is fixed. Many thanks to my provider that made me go nuts :-),
> and thanks to everybody on the mailinglist that tried to help me out.
>
> Greetz,
> Jo
May your link have continued good health.
* Heather Stern * star@ many places...
--
To UNSUBSCRIBE, email to debian-laptop-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: