Afficher un message
Vieux 04/10/2006, 22h06   #6
robert
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: ssh_exchange_identification uClinux problem

I've learned alot doing "sshd -De" from scatch. That should me on
the inetd part - which has to be that way because of resource issues on
this embedded system. I'm continuing this thread in the context I end
up hopefully with inetd working with sshd. I get:

Bind to port 22 on 0.0.0.0 failed: Address already in use.

Doing netstat shows nothing is listening on port 22. I tried starting
on port 99 - nothing there - and got the same 0.0.0.0 bind message. I
was, however, able to bind on the static address I gave the nic.
Strange. Goggling shows a message about ipv6, but its disabled in this
kernel.

I can log in via -D. but only some of my keys are recognized:

debug2: load_server_config: filename /etc/default/sshd_config
debug2: load_server_config: done config len = 284
debug2: parse_server_config: config /etc/default/sshd_config len 284
debug1: sshd version OpenSSH_4.3p2
debug1: private host key: #0 type 0 RSA1
debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA

I think the permissions are right. Why is it trying to load my dsa key
as RSA1 ? This is my config:

# HostKey for protocol version 1
HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

Thanks!
Robert

René Berber wrote:
> 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,08586 seconds with 9 queries