SSH can be used for encrypted login over the network or for encrypted file transfer between your host and the module. Our demo images use systemd's socket mechanism to start a ssh server on demand whenever the user tries to connect to the module.
On Linux, usually SSH is executed from the terminal and comes installed on some distros. For reference, here's how to install it in Debian-based distros (tested on Ubuntu 18.04 LTS):
$ sudo apt install openssh-client
On Windows, a commonly used SSH client is putty. There is also the option to start a bash instance on Windows 10.
By using the Linux command line SSH client
ssh one can establish a connection as follows:
[user@host ~]$ ssh email@example.com The authenticity of host '192.168.10.2 (192.168.10.2)' can't be established. ECDSA key fingerprint is SHA256:7aPobNtSjX9HYLr4HvyvpL7dkDTxi0uAfRRjTVqGbis. ECDSA key fingerprint is MD5:ae:ef:61:ac:bc:5f:e9:d7:48:ad:17:75:d6:a1:e2:b0. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.10.2' (ECDSA) to the list of known hosts. firstname.lastname@example.org's password: Last login: Tue Nov 3 02:44:09 2015 root@apalis-imx6:~#
Our Ångström-based embedded Linux BSP has default user configured as root and no password.
Our Torizon embedded Linux BSP has default SSH user configured as torizon and password torizon as well. Though the root connection can only be issued from the debug serial port, the torizon user has root privileges and you can execute
su just like on a regular desktop Linux distro.
During development, it's annoying to type your password every time you need to e.g.
ssh into the board or
scp a file to it.
To configure passwordless connection you should start a terminal (linux) or bash.exe (Windows 10) and run the following commands:
$ ls $HOME/.ssh
If you already have files named id_rsa and id_rsa.pub you can skip those steps, otherwise you have to create your security keys to be able to use them for ssh connections:
$ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: ... The key's randomart image is: ...
Now you can copy the keys to the target device and enable ssh login without password. In this sample we are using 192.168.1.114 as the device ip address, please replace it with the actual address/hostname of your device. Please notice that commands after the "#" prompt will be executed on the target device via ssh.
$ scp $HOME/.ssh/id_rsa.pub email@example.com:/home/torizon firstname.lastname@example.org's password: id_rsa.pub 100% 396 0.4KB/s 00:00 $ ssh email@example.com firstname.lastname@example.org's password: Last login: Thu May 2 16:09:13 2019 from 192.168.1.3 # cat id_rsa.pub >> .ssh/authorized_keys # rm id_rsa.pub # exit logout Connection to 192.168.1.114 closed. # ssh email@example.com Last login: Fri May 3 09:35:43 2019 from 192.168.1.2
If everything works as expected, the second time you tried to connect to the device you should have been able to do it without typing the password.
By default, ssh is configured as a service started by systemd's socket activation method. The connection attempts and current active connections can be gained from the socket unit:
# systemctl status sshd.socket
journalctl can be used to print log messages related to the ssh server:
# journalctl -u sshd*
This section provides insight about ssh configuration as well as known issues.
The images typically ship with a empty root password (enabled by OpenEmbedded
debug-tweaks). The system's user password can be changed by using
passwd. In order to keep being able to login as a user, make sure the following ssh daemon configurations are set (in /etc/ssh/sshd_config):
PasswordAuthentication yes #PermitEmptyPasswords yes
Depending on the SSH flavour and version both on the target (e.g. part of our BSPs) resp. client (e.g. your Linux development workstation) side there are some known cipher incompatibilities which result in the following behaviour:
[user@host ~]$ ssh firstname.lastname@example.org ssh_packet_read: Connection closed
Looking more closely the following happens:
[user@host ~]$ ssh -v email@example.com OpenSSH_7.1p1, OpenSSL 1.0.2e-fips 3 Dec 2015 debug1: Reading configuration data /home/user/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 56: Applying options for * debug1: Connecting to 192.168.10.2 [192.168.10.2] port 22. debug1: Connection established. debug1: identity file /home/user/.ssh/id_rsa type 1 debug1: key_load_public: No such file or directory debug1: identity file /home/user/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/user/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/user/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/user/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/user/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/user/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7 debug1: match: OpenSSH_6.7 pat OpenSSH* compat 0x04000000 debug1: Authenticating to 192.168.10.2:22 as 'root' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client firstname.lastname@example.org <implicit> none debug1: kex: client->server email@example.com <implicit> none debug1: kex: firstname.lastname@example.org need=64 dh_need=64 debug1: kex: email@example.com need=64 dh_need=64 debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ecdsa-sha2-nistp256 SHA256:7aPobNtSjX9HYLr4HvyvpL7dkDTxi0uAfRRjTVqGbis debug1: Host '192.168.10.2' is known and matches the ECDSA host key. debug1: Found key in /home/user/.ssh/known_hosts:232 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent ssh_packet_read: Connection closed
This can be worked around by either specifying the cipher to be used on the command line as follows:
[user@host ~]$ ssh -oCiphers=aes128-ctr firstname.lastname@example.org Last login: Wed Jan 13 08:44:12 2016 from 192.168.10.1 root@apalis-imx6:~#
Or one can permanently configure a cipher to be used in one of your SSH configuration files as follows:
[user@host ~]$ cat ~/.ssh/config Host 192.168.10.* Ciphers aes128-ctr PreferredAuthentications password PubkeyAuthentication no
Please also find further information in the following discussion initiated by us: