Afficher un message
Vieux 04/10/2006, 11h16   #4
René Berber
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: ssh_exchange_identification uClinux problem


robert wrote:
[snip]
> This is what I get from the client - the servers only debug statement
> is when it loads sshd_config:
>
> /home/iksrazal/work/tweak/uClinux-dist> ssh -vvv -l root 10.101.42.101

Problem
----------------------------------------------------------------^^^^^
By default sshd does not let root login into a server.

Are you using the default sshd_config?

> OpenSSH_3.9p1, OpenSSL 0.9.7e 25 Oct 2004
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for *
> debug2: ssh_connect: needpriv 0
> debug1: Connecting to 10.101.42.101 [10.101.42.101] port 22.
> debug1: Connection established.
> debug1: identity file /home/iksrazal/.ssh/identity type -1
> debug1: identity file /home/iksrazal/.ssh/id_rsa type -1
> debug1: identity file /home/iksrazal/.ssh/id_dsa type -1


As you say, this means that the user has not been configured to use ssh
(no keys for the user at the client computer).

> ssh_exchange_identification: Connection closed by remote host


Not the usual error response...

> [linux(iksrazal)]
> /home/iksrazal/work/tweak/uClinux-dist> telnet 10.101.42.101 22
> Trying 10.101.42.101...
> Connected to 10.101.42.101.
> Escape character is '^]'.
> Connection closed by foreign host.


Also not the usual response.

Something is listening on port 22, but it is not sshd and it could be
inetd as you have configured but you'll have to see on the server if
inetd started sshd or logged an error.

Did the connection close fast?

If you read the man page for sshd, the description of option -i says
that it may take a long time to respond. I have never used it from
inetd so I'm not sure if it is inetd closing the connection or
something else (like a firewall).

[snip]
> I tried that on both the client and server side and got basically the
> same result, using several variations of keys.


First set the user's keys on the client, the ones that show above as
non-existent.

Second, set up a user on the server or, if you really want to use root,
then change the server configuration, it's just one line that need to
be changed.

Then try to test on the server (i.e. ssh localhost) and see if sshd at
least starts.

Another test could be to run "sshd -De" on the server, without inetd
starting it, and see if that way you can connect from the client.

You may have to play with the parameters to finally make sshd work from
inetd under that server.
--
René Berber

  Réponse avec citation
 
Page generated in 0,05995 seconds with 9 queries