On Tue, Jun 18, 2002 at 06:14:04PM -0700, Heather Stern wrote: Thanks for your help Heather, but it was a network problem at my provider. Everything works now without a change in my config.
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] works just fine like it should. > > Good, but that suggests that it's not permissions in [EMAIL PROTECTED]'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 [EMAIL PROTECTED] and [EMAIL PROTECTED] > > 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. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
