sshd_config empty

    Hi,


    I have my sshd_config file totally empty.
    When booting the board I get the message " Starting sshd: OK" but it does not generate keys.
    I have mounted the file system as "rw" and restart sshd executing "S50sshd restart" in "int.d" folder. Nothing happens.


    How can I check if sshd server is up and running?
    Do I have to activate any option when compiling buildroot for ssh to work?


    Thanks.

    Hi,


    you could try this:

    Code
    1. # rm /etc/ssh/ssh_host_*


    In sshd_config, write this:

    Code
    1. Port 22
    2. AdressFamily any
    3. ListenAddress 0.0.0.0
    4. PermitRootLogin yes


    And set the current date (with date command) before starting sshd again, to generate the keys properly and not to get an expiration error.

    Hi,
    thanks a lot for your response. irisangel.


    After applying your solution nothing happens.
    The content of my ssh folder is the following:
    * ssh_config --> empty
    *sshd_config--> empty
    *moduli --> empty


    I have never had any "ssh_host_*" file.


    Thanks again !

    Thanks again but in my case, it does not work. Furthermore, I do not have any ssh_host_* file and after rebuilding builroot+kernel and carrying out same steps, unfortunately the same out come.


    Thanks.


    One more detail I can add is that in my folder /var/run there is not a sshd.pid file with the process ID, meaning it is not running, is not it?

    Does SSH only fail with your own rootfs? Have you tried with the included binary rootfs from the release? Does it work there?


    The keys are only created once. If it is done, then you will not see this again (unless you delete the keys again). So maybe you do not see the key creation because it is already done?


    The following command sequence in U-Boot should work:


    Code
    1. run .mode_rw
    2. boot


    This starts the system once in read-write mode which creates the keys. You should shut down the system properly in this case, e.g. with halt. At the next start, the rootfs is again read-only, because we did not save the setting.


    Your F&S Support Team

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    I can add one more thing.


    I have an older compilation where I got four files:
    *uImage
    * rootfs.ubifs
    * rootfs.ext4
    * armstonea9.dtb
    In this compilation, SSH works fine.


    In my other compilations, instead of those files y get these:
    *uImage
    * rootfs.ubifs
    * rootfs.ext2
    * armstonea9.dtb
    *Link to rootfs.ext4 that points to nothing


    Could this be relevant ??


    I am not using the first built because It does not have LVDS output, and I need it.


    Thanks !!

    More details:


    /etc/init.d/S50sshd script points to /usr/bin/sshd script that does not exist.
    In that folder (/usr/bin/) i can find among others:
    -rwxr-xr-x 1 root root 0 May 28 19:10 ssh*
    -rwxr-xr-x 1 root root 0 May 28 19:10 ssh-add*
    -rwxr-xr-x 1 root root 0 May 28 19:10 ssh-agent*
    -rwxr-xr-x 1 root root 0 May 28 19:10 ssh-keygen*
    -rwxr-xr-x 1 root root 0 May 28 19:10 ssh-keyscan*


    but not sshd script.


    Each time I execute /etc/init.d/S50sshd I can see that inside /var/lock a new file named sshd is created, and the final message of the process is "Starting sshd: OK" , just as the script has to do... but keys are not generated because sshd script in /usr/bin does not exist.


    This is the problem...but...how can I solve it??

    Quote from siteco.desarrollo


    I am not using the first built because It does not have LVDS output, and I need it.


    The list of different files shows that you have configured something different. Activating LVDS is just a matter of changing the device tree, you do not need to reconfigure anything else in Buildroot.


    What steps have you done? You say you have built Buildroot anew. So I assume you did a make clean or even make distclean. What did you change in the configuration to compile the new version. What default configuration have you loaded? When using our fsimx6_defconfig, SSH should be configured to work.


    Your F&S Support Team

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    Apart from LVDS and SSH, I need git, python and flask.
    What I do in order to compile this way is launch "make menuconfig" and change settings.
    After that, just "make".
    So far this is what I need, but I think that I will have to include more packages such as Mysql soon.

    Hello again,


    I have made a built again, and this time it worked. I do not why but the thing is that now I have python, SSH, git, flask, and every thing i need till today.


    Thanks for your support.


    FYI: In the built working, rootfs.ext4 is a link too. It does not seem to be relevant.

    A possible explanation would be some non-consistent package modifications.


    When Buildroot is built for the first time, it builds for the current configuration. At the same time it also creates so-called stamp files for each completed stage, i.e. some dummy files that tell Buildroot that it already has fully done this stage and does not need to do it again at the next make. This works well if you do not change your configuration significantly. However if you do some changes that would also require recompilation of some package, then you get an inconsistent system, because Buildroot will not do this recompilation on its own. You either have to trigger recompilation of this package manually or you have to clean the project and build everything anew.


    Let's do an example. gstreamer is the multimedia environment of Linux. It is also part of our regular standard root filesystem. This standard rootfs uses X11, which means gstreamer can use a backend to output videos to an X11 window. Now if you reconfigure Buildroot and remove the X11 package and use Wayland instead, then two things happen:

    • Of course, buildroot compiles the new packages required for Wayland support
    • Buildroot can *not* remove X11 from the existing rootfs, because it does not track installed files and there is no Makefile rule to remove all installed files. Therefore X11 stays available in your rootfs for the time being.

    But as the stamp files for gstreamer are still valid, gstreamer is not rebuilt in this case. Which means gstreamer still wrongly has X11 access and still misses Wayland access. So doing such a significant change of the graphical subsystem also requires to rebuild other packages, like gestreamer. So you could call

    Code
    1. make gstreamer-reconfigure


    to reconfigure and recompile the gstreamer package. But gstreamer also has sub-packages for all the plugins, so this is not sufficient, you need at least three additional reconfigure commands. And this is certainly no the only package that is affected by such a change. However it is very difficult to tell what packages exactly need to be rebuilt after such a change. So in this case I would strongly recommend a complete rebuild with


    Code
    1. make clean
    2. make


    Something similar may have happened in your case. You have added packages but the necessary support code to interact with these packages was still missing from *other* packages that were already enabled before. So if you have such strange error messages, it is always a good idea to rebuild Buildroot anew. This also has the advantage that all packages that you have newly disabled now actually disappear from the rootfs. Or more precisely they will never be part of the newly built rootfs.


    Actually when you are done with development and want to release your software, we recommend doing a final full clean build and some final tests before using the software in a productive environment. This ensures the smallest possible root filesystem and the smallest risk of problems because of inconsistently configured packages.


    ATTENTION! Please note that make clean really removes the whole output directory. So please be sure to save any source code modifications that you have done under output/build and all manual changes that you have done to the rootfs skeleton in output/target before you call this command.


    Your F&S Support Team

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    Edited once, last by fs-support_HK ().