Author: Siro Mugabi

Category: development setups


A few OpenSSH configurations typically used in embedded development setups are presented here. SSH protocol version 2 is assumed.

Tags: openssh development setups


For illustration purposes, the QEMU VLAN setup is used here. The configuration basically consists of a QEMU VM gateway serving QEMU VM client nodes on a private VLAN.

This setup is used to simulate a scenario where embedded development targets are connected to a private LAN behind a development PC and gateway machine. It also applies to a typical paravirtualized hypervisor configuration i.e. domain0, with access to the hardware, providing a virtual network to the other domains/partitions via, say, virtio-net.

The QEMU VM host is assumed to have the following (Linux bridge) network interface configuration:

$ /sbin/route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface         UG    100    0        0 br0   U     0      0        0 br0

Its IP address could be any valid address for the subnet e.g:

$ ip -4 address | grep inet | grep br0
   inet brd scope global br0

The following is the QEMU VM gateway network inteface configuration used:

$ ifconfig
br0       Link encap:Ethernet  HWaddr de:ad:be:ef:51:12  
          inet addr:  Bcast:  Mask:
eth0      Link encap:Ethernet  HWaddr de:ad:be:ef:00:11  
          inet addr:  Bcast:  Mask:
eth1      Link encap:Ethernet  HWaddr de:ad:be:ef:51:12  

$ /sbin/route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface         UG    0      0        0 eth0   U     0      0        0 eth0   U     0      0        0 br0

Finally, the QEMU VM clients network interfaces are configured for (private QEMU VLAN) subnet For example, QEMU VM node0:

$ ip -4 address | grep eth0 | grep inet
inet brd scope global eth0

$ /sbin/route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface         UG    0      0        0 eth0   U     1      0        0 eth0

Refer to A QEMU VLAN Setup for background information on setting up the VM network configuration described above.

Local/Direct Port Forwarding

On the (QEMU VM) gateway:

$ ssh -l $USER -L 9002:localhost:22 -gfN
$ ssh -l $USER -L 9003:localhost:22 -gfN


  • -g enables other nodes on subnet to also use the gateway's port forwarding configuration.

  • -f runs ssh in the background.

  • -N prevents execution of remote commands.

Consult ssh(1) for a more detailed description of these and other options.

SSH will forward inbound requests arriving on eth0 and of the (QEMU VM) gateway and ports 9002 or 9003 to port 22 (sshd) of its respective (QEMU VM) clients. So, to login directly to a (QEMU VM) client on the private development LAN from a machine on subnet, e.g. the QEMU VM host itself:

  • For client

    [vm_host:~]$ ssh  lumumba@ -p 9002
    lumumba@'s password: <enter $USER password for>
    [vm_node0:~]$ ip -4 address | grep inet | grep eth0
            inet brd scope global eth0
  • For client

    [vm_host:~]$ ssh  lumumba@ -p 9003
    lumumba@'s password: <enter $USER password for>
    [vm_node1:~]$ ip -4 address | grep inet | grep eth0
            inet brd scope global eth0

SSH without Password/Key Authentication

It is assumed that the security implications of disabling SSH authentication are well understood. Essentially, disabling authentication defeats the purpose of a secure communication channel. Nevertheless, this is presented in the context of an embedded development setup where the primary concern is some form of connectivity in a private LAN: remote login (ssh), data transfer (scp/sftp), file sharing (sshfs), etc, and working convinience.

Conventionally, user (public/private) key pairs are used not only to replace the use of passwords (working convinience), but also provide a greater degree security. Nevertheless, this requires the presence (and distribution) of the key pairs. This is often impractical or unecessary in development setups. For instance, the development platforms of the Linaro GNU/Linux ARM distro releases configure an SSH no-key-no-password setup rather than maintaining and supplying SSH keys for each release.


For the initial configuration and test, the sshd configuration file is copied and used from a temporary location e.g.

$ cd
$ cp /etc/ssh/sshd_config sshd_config_test

Now, edit sshd_config_test such that:

  • PasswordAuthentication yes

    Enable password authentication.

  • PermitEmptyPasswords yes

    If used in combination with PasswordAuthetication yes, then this option allows login to accounts with empty password strings.

  • PermitRootLogin yes

    Allow root user logins.

  • UsePAM no

    Disable Pluggable Authentication Module (PAM) authentication.

  • ChallengeResponseAuthentication no

    Disable challenge-response authentication (e.g. via PAM).

Apperently, in addition to the above sshd_config_test settings, the password field in /etc/shadow must be blanked out. Otherwise SSH will still request user password authentication.

CAUTION: An encrypted password must exist in the corresponding field in /etc/passwd when blanking out the password field of the respective user in /etc/shadow. Otherwise, the user may not be able to login (or sudo) again.

So, for example, on the SSH server (with local root login disabled):

$ cat /etc/shadow | egrep '(root|lumumba)'

$ cat /etc/passwd | egrep '(root|lumumba)'

NOTE: SSH root login will still work even if local root login is disabled i.e:

$ su --login root
Password: <type-root-password>
su: Authentication Failure


On the SSH server, fire up an sshd instance in debug mode against sshd_config_test and on a non-standard port:

$ sudo /usr/sbin/sshd -f sshd_config_test -p 9999 -d

On the SSH client (for instance, performing root login):

$ ssh root@${SSH_SERVER} -p 9999

Note that for first time client connections, sshd still sends and requests verification of its its public key (fingerprint) e.g:

$ ssh root@ -p 9999
The authenticity of host '[]:9999 ([]:9999)' can't be established.
RSA key fingerprint is 09:b8:d3:49:22:33:d7:b8:0a:64:c8:45:91:99:b4:cd.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[]:9999' (RSA) to the list of known hosts.
Last login: Sun Dec 18 

However, once the client accepts this request (i.e. stores the server's public key in ~/.ssh/known_hosts), subsequent login/connection attempts will proceed without any user interaction.

Once satisfied with the configuration, sshd_config_test may now be moved to the system directory, e.g. /etc/ssh/sshd_config, and sshd restarted for the new settings to take effect. For example, in Debian/Ubuntu:

$ sudo service ssh restart

At this point, ssh, scp, sftp, sshfs, etc should work transparently (standard port 22) without requesting user key or password authentication.

Combining Local Port Forwarding with no-key-no-passwd Authentication

Back to the QEMU VLAN setup, since there already exist forwarding connections on the VM gateway:

$ ps ax | grep ssh | egrep '(9002|9003)'
24246 ?        Ss     0:00 ssh -l lumumba -L 9002:localhost:22 -gfN
24248 ?        Ss     0:00 ssh -l lumumba -L 9003:localhost:22 -gfN

$ sudo netstat -tunelp | egrep '(9002|9003)'
tcp        0      0  *               LISTEN      1000       72879       24246/ssh       
tcp        0      0  *               LISTEN      1000       72895       24248/ssh

Simply replace /etc/ssh/sshd_config of the QEMU VM client nodes with the no-key-no-passwd SSH server configuration file described in the previous section and restart sshd e.g:

[vm_node0:~]$ sudo cp sshd_config_test /etc/ssh/sshd_config
[vm_node0:~]$ sudo service ssh restart

Then edit/configure /etc/passwd and /etc/shadow accordingly. That's it. Now, from a terminal on the QEMU Host:

[vm_host:~]$ ssh root@ -p 9002

[vm_node0:~]$ ifconfig
eth0      Link encap:Ethernet  HWaddr de:ad:be:ef:b1:ab  
          inet addr:  Bcast:  Mask:

i.e. direct login to a client on from a machine on with no-key-no-passwd authentication.


  • $USER in the SSH command line of the intermediary forwarding SSH server1 can be any valid SSH login account on the final SSH target on subnet For instance, even if lumumba was used, a client on subnet could still login a host on with root (as shown above).

  • The sshd configuration of the gateway does not affect the no-key-no-passwd setup of the final SSH targets on For example, the /etc/ssh/sshd_config used in the gateway was the default Ubuntu configuration. Login to the hosts on subnet was possible without key/password authentication while SSH connections to the gateway itself still required user key or password authentication:

    $ ssh lumumba@
    lumumba@'s password:


1. See Section link [go back]