SSH connection not possible.

[Erik J]

Everytime I try to make a connection with ssh, I get the following message.

ssh_exchange_identification: Connection closed by remote host

erik@asus:~$ ssh -v ro...@my-ip.55
OpenSSH_5.9p1 Debian-5ubuntu1.4, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.1.100 [192.168.1.100] port 22.
debug1: Connection established.
debug1: identity file /home/erik/.ssh/id_rsa type -1
debug1: identity file /home/erik/.ssh/id_rsa-cert type -1
debug1: identity file /home/erik/.ssh/id_dsa type -1
debug1: identity file /home/erik/.ssh/id_dsa-cert type -1
debug1: identity file /home/erik/.ssh/id_ecdsa type -1
debug1: identity file /home/erik/.ssh/id_ecdsa-cert type -1
ssh_exchange_identification: Connection closed by remote host

I stopped services dropbear and sshd at the same time, the same after restart. (no ssh services when they were turned off)
I also did a reboot, same problem.

Tried to localize the id_rsa files to delete them, and found they are not there.
The only hidden dir in my home dir is .ash_history
Solutions at http://edoceo.com/notabene/ssh-exchange-identification were of no use.

Also tried to set up  /ffp/sbin/sshd

Please contact your system administrator.
Add correct host key in /home/erik/.ssh/known_hosts to get rid of this message.

but no way i can find the offending file to delete it.

Where lies the solution?

Thanks again.

[João Cardoso]

On Sunday, January 25, 2015 at 2:28:21 PM UTC, Erik J wrote:

Everytime I try to make a connection with ssh, I get the following message.

ssh_exchange_identification: Connection closed by remote host

erik@asus:~$ ssh -v ro...@my-ip.55
OpenSSH_5.9p1 Debian-5ubuntu1.4, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.1.100 [192.168.1.100] port 22.
debug1: Connection established.
debug1: identity file /home/erik/.ssh/id_rsa type -1
debug1: identity file /home/erik/.ssh/id_rsa-cert type -1
debug1: identity file /home/erik/.ssh/id_dsa type -1
debug1: identity file /home/erik/.ssh/id_dsa-cert type -1
debug1: identity file /home/erik/.ssh/id_ecdsa type -1
debug1: identity file /home/erik/.ssh/id_ecdsa-cert type -1

This just means that you don't have ssh keys on your client computer 

ssh_exchange_identification: Connection closed by remote host

It must be your ssh client configuration...

 

I stopped services dropbear and sshd at the same time,

Have you edit its configuration? What is dropbear configuration? (Services->Network->inetd->ssh, Configure)

By default both dropbear are openSSH sshd are under inetd control and are listening respectively on port 22 and on port 2222.

 

the same after restart. (no ssh services when they were turned off)
I also did a reboot, same problem.

Tried to localize the id_rsa files to delete them, and found they are not there.
The only hidden dir in my home dir is .ash_history
Solutions at http://edoceo.com/notabene/ssh-exchange-identification were of no use.

Also tried to set up  /ffp/sbin/sshd

You can't have more then one (sshd) server running on the same port. To debug something you must have the most simple configuration -- disable ffp sshd.

 

Please contact your system administrator.
Add correct host key in /home/erik/.ssh/known_hosts to get rid of this message.

but no way i can find the offending file to delete it.

 

There are no offending files to delete

[Erik J]

El lunes, 26 de enero de 2015, 17:42:13 (UTC+1), João Cardoso escribió:

On Sunday, January 25, 2015 at 2:28:21 PM UTC, Erik J wrote:

Everytime I try to make a connection with ssh, I get the following message.

ssh_exchange_identification: Connection closed by remote host

erik@asus:~$ ssh -v ro...@my-ip.55
OpenSSH_5.9p1 Debian-5ubuntu1.4, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.1.100 [192.168.1.100] port 22.
debug1: Connection established.
debug1: identity file /home/erik/.ssh/id_rsa type -1
debug1: identity file /home/erik/.ssh/id_rsa-cert type -1
debug1: identity file /home/erik/.ssh/id_dsa type -1
debug1: identity file /home/erik/.ssh/id_dsa-cert type -1
debug1: identity file /home/erik/.ssh/id_ecdsa type -1
debug1: identity file /home/erik/.ssh/id_ecdsa-cert type -1

This just means that you don't have ssh keys on your client computer 

ssh_exchange_identification: Connection closed by remote host

It must be your ssh client configuration...

Ok, I believe you. Still strange, almost sure I did log in from this computer, but will set it up as soon as I can.
 

 

I stopped services dropbear and sshd at the same time,

Have you edit its configuration? What is dropbear configuration? (Services->Network->inetd->ssh, Configure)

No, I did not edit. Still under inetd conrol and both are listening on port 22. I noticed that they are linked, you cannot let dropbear listen on 22 and the  sshd on 2222.
 

By default both dropbear are openSSH sshd are under inetd control and are listening respectively on port 22 and on port 2222.

 

the same after restart. (no ssh services when they were turned off)
I also did a reboot, same problem.

Tried to localize the id_rsa files to delete them, and found they are not there.
The only hidden dir in my home dir is .ash_history
Solutions at http://edoceo.com/notabene/ssh-exchange-identification were of no use.

Also tried to set up  /ffp/sbin/sshd

You can't have more then one (sshd) server running on the same port. To debug something you must have the most simple configuration -- disable ffp sshd.

Yes, when i was trying the ffp sshd, i had the dropbear and sshd with inetd disabled.
 

 

Please contact your system administrator.
Add correct host key in /home/erik/.ssh/known_hosts to get rid of this message.

but no way i can find the offending file to delete it.

 

There are no offending files to delete

Good! I thought the key files were to be created automatically, and that there was something intermingling the wrong keys because of my messing up with hd and raids and Alt-F folder on the hd.


Thanks again.!!!
 

[Erik J]

Hello, back again.

I had this problem solved for a while, by making new keys at the client side but after running the update, and the fix,
the server is pretending the same problem as described below, but in the system log file I find this line when trying to login with ssh from my client.

Feb  8 00:32:40 terra daemon.err inetd[2622]: can't execute '/usr/sbin/sshd': No such file or directory

and yes, it is not there. What to do?

Thanks in advance!

e.

[João Cardoso]

On Monday, February 9, 2015 at 8:24:37 PM UTC, Erik J wrote:

Hello, back again.

I had this problem solved for a while, by making new keys at the client side but after running the update, and the fix,
the server is pretending the same problem as described below, but in the system log file I find this line when trying to login with ssh from my client.

Feb  8 00:32:40 terra daemon.err inetd[2622]: can't execute '/usr/sbin/sshd': No such file or directory

and yes, it is not there. What to do?

 

/usr/sbin/sshd is the openssh server, and belongs to the openssh package. If it is not there, you either deleted it or the Alt-F folder does not exists. uninstall and reinstall the openssh package.

[Erik J]

yes and no. I did never delete the alt-F folder. BUT, sometimes it takes a while after a reboot untill the machine finds the Alt-F folder. Anyway, a reboot never works automatically, it takes more than 5 minutes, and i push the button....

So I looked at the openssh package, it states I could install it. I pushed the install button.

got this:

Nothing to be done
An error ocurred, return value: 4.
Collected errors:
Cannot find package openssh.
Check the spelling or perhaps run 'ipkg update'

So I ran the ipkg update, and surprise, nothing left under "available packages". See screenshot.

In my system log, I see many memory faults, can it be a hardware failure?

Brand new box, bought it because it was cheap, and because I knew there was Alt-F available.

Thanks!





 

[João Cardoso]

On Tuesday, February 10, 2015 at 6:36:47 PM UTC, Erik J wrote:

El martes, 10 de febrero de 2015, 19:05:34 (UTC+1), João Cardoso escribió:

On Monday, February 9, 2015 at 8:24:37 PM UTC, Erik J wrote:

Hello, back again.

I had this problem solved for a while, by making new keys at the client side but after running the update, and the fix,
the server is pretending the same problem as described below, but in the system log file I find this line when trying to login with ssh from my client.

Feb  8 00:32:40 terra daemon.err inetd[2622]: can't execute '/usr/sbin/sshd': No such file or directory

and yes, it is not there. What to do?

 

/usr/sbin/sshd is the openssh server, and belongs to the openssh package. If it is not there, you either deleted it or the Alt-F folder does not exists. uninstall and reinstall the openssh package.

yes and no. I did never delete the alt-F folder. BUT, sometimes it takes a while after a reboot untill the machine finds the Alt-F folder.

If is found when the filesystem where it belongs is mounted.

 

Anyway, a reboot never works automatically,

??? what do you mean?

 

it takes more than 5 minutes, and i push the button....

What button? webUI reboot button? front power button?

 

So I looked at the openssh package, it states I could install it. I pushed the install button.

got this:

Nothing to be done
An error ocurred, return value: 4.
Collected errors:
Cannot find package openssh.
Check the spelling or perhaps run 'ipkg update'

So I ran the ipkg update, and surprise, nothing left under "available packages". See screenshot.

Sourceforge is currently out of order:

We're sorry -- the Sourceforge site is currently in Disaster Recovery mode, and currently requires

the use of javascript to function.  Please check back later.

Try tomorrow again.

In my system log, I see many memory faults, can it be a hardware failure?

Do you mean the "__nand_correct_data: uncorrectable ECC error<3>end_request: I/O error, dev mtdblock0, sector 0"? I never saw that error. It comes from the NAND flash memory.

In principle, the offending NAND bad sector is copied and remapped to a good sector, just as it happens on a disk, but it looks like that the copy (and remapping) failed... it is a hardware fault that is important for the correct system operation.

A normal NAND error is like (from your log)

Feb  7 22:40:25 terra user.warn kernel: Bad eraseblock 243 at 0x000001e60000

Feb  7 22:40:25 terra user.warn kernel: Bad eraseblock 796 at 0x000006380000

Feb  7 22:40:25 terra user.warn kernel: Bad eraseblock 994 at 0x000007c40000

What's your box model and hd rev?

[Erik J]

El martes, 10 de febrero de 2015, 20:03:07 (UTC+1), João Cardoso escribió:

On Tuesday, February 10, 2015 at 6:36:47 PM UTC, Erik J wrote:

El martes, 10 de febrero de 2015, 19:05:34 (UTC+1), João Cardoso escribió:

On Monday, February 9, 2015 at 8:24:37 PM UTC, Erik J wrote:

Hello, back again.

I had this problem solved for a while, by making new keys at the client side but after running the update, and the fix,
the server is pretending the same problem as described below, but in the system log file I find this line when trying to login with ssh from my client.

Feb  8 00:32:40 terra daemon.err inetd[2622]: can't execute '/usr/sbin/sshd': No such file or directory

and yes, it is not there. What to do?

 

/usr/sbin/sshd is the openssh server, and belongs to the openssh package. If it is not there, you either deleted it or the Alt-F folder does not exists. uninstall and reinstall the openssh package.

yes and no. I did never delete the alt-F folder. BUT, sometimes it takes a while after a reboot untill the machine finds the Alt-F folder.

If is found when the filesystem where it belongs is mounted.

 

Anyway, a reboot never works automatically,

??? what do you mean?

 

it takes more than 5 minutes, and i push the button....

What button? webUI reboot button? front power button?

sorry front power button, to finish the reboot. it means, a hard shutdown then, and i push it again to do the start-up.

 

So I looked at the openssh package, it states I could install it. I pushed the install button.

got this:

Nothing to be done
An error ocurred, return value: 4.
Collected errors:
Cannot find package openssh.
Check the spelling or perhaps run 'ipkg update'

So I ran the ipkg update, and surprise, nothing left under "available packages". See screenshot.

Sourceforge is currently out of order:

We're sorry -- the Sourceforge site is currently in Disaster Recovery mode, and currently requires

the use of javascript to function.  Please check back later.

Try tomorrow again.

ok, or thursday
 

In my system log, I see many memory faults, can it be a hardware failure?

Do you mean the "__nand_correct_data: uncorrectable ECC error<3>end_request: I/O error, dev mtdblock0, sector 0"?

yes, and googling this error is not so easy.
 

I never saw that error. It comes from the NAND flash memory.

In principle, the offending NAND bad sector is copied and remapped to a good sector, just as it happens on a disk, but it looks like that the copy (and remapping) failed... it is a hardware fault that is important for the correct system operation.

 

A normal NAND error is like (from your log)

Feb  7 22:40:25 terra user.warn kernel: Bad eraseblock 243 at 0x000001e60000

Feb  7 22:40:25 terra user.warn kernel: Bad eraseblock 796 at 0x000006380000

Feb  7 22:40:25 terra user.warn kernel: Bad eraseblock 994 at 0x000007c40000

What's your box model and hd rev?

dns 320L A3

[Erik J]

Now sourceforge is up and running again, the ssh issue has been solved.

but still no proper software reboot possible, and one question, how many of these hardware memory faults ["__nand_correct_data: uncorrectable ECC error<3>end_request: I/O error, dev mtdblock0, sector 0"?] are fatal for the Alt-F operating system. 5 lines in the log, or 50?? Buyers guarantee is gone, I suppose, as soon as the box is flashed.

thanks

e.

[João Cardoso]

On Thursday, February 12, 2015 at 7:00:49 PM UTC, Erik J wrote:

Now sourceforge is up and running again, the ssh issue has been solved.

The following is getting off topic... it's better to open new topics for new discussions/issue.

 

but still no proper software reboot possible,

[copied from other post:] 

Anyway, a reboot never works automatically,

??? what do you mean?

 

it takes more than 5 minutes, and i push the button....

What button? webUI reboot button? front power button?

sorry front power button, to finish the reboot. it means, a hard shutdown then, and i push it again to do the start-up. 

So you mean that hitting the Reboot web button in System->Utilities does not works? And hitting the PowerOff web button works?

The box front power button does the same action as the PowerOff web button, namely executing the '/usr/sbin/poweroff' command, while the Reboot web button executes the '/sbin/reboot' command.

None of them do a hard shutdown, both cleanly terminate running programs and unmount filesystems before performing a reboot or a power off.

 

and one question, how many of these hardware memory faults ["__nand_correct_data: uncorrectable ECC error<3>end_request: I/O error, dev mtdblock0, sector 0"?] are fatal for the Alt-F operating system. 5 lines in the log, or 50??

Well, a single bit error can have catastrophic consequences...

Imagine a script where the letter 'm' is changed to a 'r' (actually a 4 bits change): the command 'mv foo bar' (rename foo to bar) becomes 'rm foo bar' (delete foo and bar). So it depends where the error is, in general programs will crash during its execution.

But the place where the error is reported is odd. It is reported to be in mtdblock0, the flash memory partition where u-boot, the box boot-loader, is located. The boot loader is what is executed at power-up time to load and run the operating system (Alt-F), and if it is damage then the box becomes bricked. It's executed before Alt-F or the vendor's firmware. Alt-F never touches that flash "partition", even when doing firmware upgrades.

What is odd is that the error is reported when the boot loader has already successfully loaded and executed Alt-F, and has terminated. So I'm puzzled.

 

Buyers guarantee is gone, I suppose, as soon as the box is flashed.

Yes.

You can however flash back the vendor's firmware, selecting "Erase all flashed settings and flash new settings from defaults file" in the Firmware Upgrade webUI, and it will be unnoticed that another OS was ever flashed. It's up to you.

If you do that you can't know if the error persists or not.