Re: Weird ssh problem
On Sun, Jun 16, 2002 at 06:35:55PM +0200, Jo Geraerts wrote:
> To: secureshell@securityfocus.com
> Subject: Weird ssh problem
>
> Hello everybody,
>
> I've got a weird ssh problem here.
>
> i can't login with ssh on jgeraert@host1. (host1=D577FF3DDF.kabel.telenet.be or kcnet.dnsalias.org) ssh doesn't ask for a password.
>
> note: sshd on host1 is running on port 2222 because the provider blocks
> all ports <1024
>
> This is the output from ssh -v:
>
> debug1: Connecting to kcnet.dnsalias.com [213.119.61.223] port 2222.
> debug1: temporarily_use_uid: 1000/1000 (e=0)
> debug1: restore_uid
> debug1: temporarily_use_uid: 1000/1000 (e=0)
> debug1: restore_uid
> debug1: Connection established.
> debug1: read PEM private key done: type DSA
> debug1: read PEM private key done: type RSA
has them in memory I think...
> debug1: identity file /home/ernie/.ssh/identity type -1
> debug1: identity file /home/ernie/.ssh/id_rsa type -1
> debug1: identity file /home/ernie/.ssh/id_dsa type -1
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
... in a context where I have an identity file (but that's not what it
wants), I have an id_rsa file (which gets used) and don't have an id_dsa
file.
So I'd interpret that as saying you don't have any keys as far as it's
concerned.
If you DO then check their permissions.
If you DON'T then create a key:
ssh-keygen -t rsa
(and follow the prompts. This will generate an id_rsa key)
> debug1: Remote protocol version 1.5, remote software version OpenSSH-1.2.3
> debug1: match: OpenSSH-1.2.3 pat ^OpenSSH
> debug1: Local version string SSH-1.5-OpenSSH_3.0.2p1 Debian 1:3.0.2p1-9
> debug1: Waiting for server public key.
> debug1: Received server public key (768 bits) and host key (1024 bits).
> debug1: Host 'kcnet.dnsalias.com' is known and matches the RSA1 host key.
Good, this means your machine likes its machine ("knows" who it is)
> 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).
> debug1: Encryption type: 3des
> debug1: Sent encrypted session key.
> debug1: Installing crc compensation attack detector.
> debug1: Received encrypted confirmation.
handshake complete, but of what? Just enough to "safely" ... well, more
safely than shouting it out loud at the mall, anyway ... discuss a plain
password.
> 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.
> Now, when i do
> ssh root@host1 everything works ok, so does
> ssh tester@host1
Those two accounts have proper permissions on their .ssh directories and
your key is allowed in, or your .shosts says your host is allowed in.
> 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.
Check your client side's logfiles, as it may contain a more useful
complaint.
If you know a sysadmin at host1 then you may find something useful in
its logfiles too.
> I have analyzed the packets with tcpdump.
> (i ran sshd also on port 2223 so i could filter the right packets out)
> server(host1) output:
>
[snipped. I don't read tcpdump very well by raw eyeball, sorry]
>
> on the client side:
> Client:
>
> tcpdump: listening on ppp0
[snipped. I don't read tcpdump very well by raw eyeball, sorry]
>
> As you can see, the packets below the line never arrive at the server?
> You can see the 28 bytes the client is trying to send also in the send-q culumn
> of netstat:
> 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?
In which case when you got hung up on, there'd always be a few lost
souls that still tried to go.
> So at this point you'll think it's a tcp/ip problem? But why
> do root@host1 and tester@host1 work alright then? I also have flushed my firewall rules
> to be sure that nothing gets blocked, but i don't think that's the problem because other
> packets arrived at the server.
>
> The server (host1) is running debian potato which with ssh:
> SSH Version OpenSSH-1.2.3, protocol version 1.5.
> Compiled with SSL.
>
> The client (my home pc) is running debian sid with ssh:
> OpenSSH_3.0.2p1 Debian 1:3.0.2p1-9, SSH protocols 1.5/2.0, OpenSSL 0x0090604
You can use -1 or -2 to force which protocol version is being tried.
> Is there anyone out there in the big big world who can help me?
> Greets,
> Jo
Well, I hope that what I said helps a little.
* 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: