Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
17 years ago

SSH broken

Under Customize Application/Library Settings

Network Applications -->

[*] ssh

[*] sshd

[*] ssh-keygen

I also enabled syslog

BusyBox -->

[*] System logging utilities -->

[*] SysLogD

I created a simple /etc/sshd_config file that set the port to 22 (default). I did this because sshd generated an error if there was no config file.

I created a host key using ssh-keygen on the nios2 hardware but it was unrecognized as a valid key file. So I generated it on my Linux PC and

copied it into the nios2 board.

I started the daemon and verified that it was running using ps. Then I ran netstat -tanl do verify that the ssh daemon was listening on port 22.

Unfortunately it was not. Looking at the log file it appears that everything was Ok until the very end when I get a "bad protocol" message.

The log is included below. Any help with this would be much appreciated. Thanks, Alex

Nov 30 00:25:27 HALFDOME_A9 auth.debug sshd[43]: debug2: load_server_config: filename /etc/sshd_config

Nov 30 00:25:27 HALFDOME_A9 auth.debug sshd[43]: debug2: load_server_config: done config len = 20

Nov 30 00:25:27 HALFDOME_A9 auth.debug sshd[43]: debug2: parse_server_config: config /etc/sshd_config len 20

Nov 30 00:25:27 HALFDOME_A9 auth.debug sshd[43]: debug3: /etc/sshd_config:1 setting port 22

Nov 30 00:25:27 HALFDOME_A9 auth.debug sshd[43]: debug3: /etc/sshd_config:2 setting protocol 2

Nov 30 00:25:27 HALFDOME_A9 auth.debug sshd[43]: debug1: sshd version OpenSSH_4.7p1

Nov 30 00:25:27 HALFDOME_A9 auth.debug sshd[43]: debug3: Not a RSA1 key file /etc/ssh_host_rsa_key.

Nov 30 00:25:27 HALFDOME_A9 auth.debug sshd[43]: debug1: read PEM private key done: type RSA

Nov 30 00:25:27 HALFDOME_A9 auth.debug sshd[43]: debug1: private host key:# 0 type 1 RSA

Nov 30 00:25:27 HALFDOME_A9 auth.debug sshd[43]: debug3: Not a RSA1 key file /etc/ssh_host_dsa_key.

Nov 30 00:25:27 HALFDOME_A9 auth.debug sshd[43]: debug1: read PEM private key done: type DSA

Nov 30 00:25:27 HALFDOME_A9 auth.debug sshd[43]: debug1: private host key:# 1 type 2 DSA

Nov 30 00:25:27 HALFDOME_A9 auth.debug sshd[43]: debug1: inetd sockets after dupping: 3, 4

Nov 30 00:25:27 HALFDOME_A9 auth.info sshd[43]: Connection from UNKNOWN port 65535

Nov 30 00:25:32 HALFDOME_A9 auth.info sshd[43]: Bad protocol version identification '' from UNKNOWN

8 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    I've had better luck using Dropbear (both server and client) versus OpenSSH (just the client). You might give it a go...

    Cheers,

    - slacker
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    Slacker may be correct that Dropbear is a better solution. I plan to look at that at some point . I did manage to get ssh working.

    First it seemd that in a uClinux environment the ssh daemon expects to be launched from inetd. So I modified the ssh makefile in

    uClinux-dist/user/ssh to add a line in the inetd.conf file to launch the Daemon.

    $(ROMFSINST) -e CONFIG_USER_SSH_SSHD -a "ssh stream tcp nowait root /bin/sshd -i" /etc/inetd.conf

    I am using a simple sshd_config file:

    Port 22

    Protocol 2

    AddressFamily inet

    I generated the host keys on my PC Linux workstation and copied them into the jffs2 file system. The RC file copies them into the /etc directory. Not very efficient.

    To start an ssh session from my workstation on the nios2 target I type:

    ssh -x -l root -T <IP ADDRESS>

    As mentioned in the initial post, I enabled the three ssh utilities in Network Applications.

    I did not need to explicitly enable ssl. There was some documentation around that indicated that it was needed. If so it is picked up automatically.

    Alex

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    That seems like a really good enhancement.

    Could you create a patch from this and send it to hippo so that he can include it in the standard distr ?

    Thanks,

    -Michael
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    Michael, I am more than happy to create a patch for the makefile. I am also currently working on the I2C/RTC problem (another active thread on this forum). Could you please point me at the instructions/method for sending the patch to hippo (I have no email address for him) and also is there something for contributing to the wiki? I am thinking a wiki entry for setting up the RTC would be nice too. Thanks, Alex
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    <div class='quotetop'>QUOTE (hippo @ Aug 5 2009, 04:29 AM) <{post_snapback}> (index.php?act=findpost&pid=23414)</div>

    --- Quote Start ---

    I have ds1307/ds1338 worked on NEEK. Please see the wiki, http://www.nioswiki.com/gpio (http://www.nioswiki.com/gpio)[/b]

    --- Quote End ---

    - Is there a cause why, on the NEEK hardware, bit baning on a GPIO port is implemented instead of using some I²C ipCore ?

    - Does this I²C interface-driver support an I²C "subsystem" so that I²C "chip driver" Kernel modules can be created that use these hardware pins as a common bus for multiple different I²C enabled chips ?

    -Michael

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    <div class='quotetop'>QUOTE (mschnell @ Aug 5 2009, 03:19 PM) <{post_snapback}> (index.php?act=findpost&pid=23416)</div>

    --- Quote Start ---

    <div class='quotetop'>QUOTE (hippo @ Aug 5 2009, 04:29 AM) <{post_snapback}> (index.php?act=findpost&pid=23414)

    --- Quote End ---

    --- Quote Start ---

    I have ds1307/ds1338 worked on NEEK. Please see the wiki, http://www.nioswiki.com/gpio (http://www.nioswiki.com/gpio)[/b]

    --- Quote End ---

    - Is there a cause why, on the NEEK hardware, bit baning on a GPIO port is implemented instead of using some I²C ipCore ?

    - Does this I²C interface-driver support an I²C "subsystem" so that I²C "chip driver" Kernel modules can be created that use these hardware pins as a common bus for multiple different I²C enabled chips ?

    -Michael

    [/b]

    --- Quote End ---

    GPIO is simple, low LE count and easy to debug. Bit banging i2c is used on almost every PC. Unless you will have high i2c traffic, gpio i2c is the better choice in term of LE usage. There is no difference in 2c chip drivers, other than the the low level interface.

    You can have multiple i2c devices on a i2c bus. Each device usually have wired i2c address. On neek, there are three independent i2c buses. Beside kernel i2c chip drivers, user space drivers through /dev/i2c-x are also supported, such as i2c-tools utility.

    Cheer,

    Hippo