SSH - Connect Through Network
Introduction
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.
Prerequisites
- SSH client application.
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 Linux subsystem with an integrated bash on Windows 10.
Establishing an SSH Connection
By using the Linux command line SSH client ssh one can establish a connection using either:
- The board IP address, for example
192.168.10.2. Learn how to find the IP address using Serial or scan your network. - The board hostname and mDNS, for example
apalis-imx8-06438725.
If you are using Torizon, it is possible to quickly re-establish a connection using the Visual Studio Code Extension for Torizon, also described further.
Using the IP Address
How to connect assuming the username is root and the IP address of the module is 192.168.10.2:
[user@host ~]$ ssh root@192.168.10.2
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.
root@192.168.10.2's password:
Last login: Tue Nov 3 02:44:09 2015
root@apalis-imx6:~#
Using the Hostname
From the unique serial number of the module, found in the board label/sticker, the board's hostname is generated, composed on the following format: <family>-<processor>-<serial number>, all lowercase letters.
If you have access to the board terminal via the Serial Port Debug Console, you can also see the hostname on the terminal right away, or get it using the hostname command:
apalis-imx8-06438725:~$ hostname
apalis-imx8-06438725
Then you must add the suffix .local to the hostname and connect using the ssh command just like it's also done when using the IP address:
ssh root@apalis-imx8-06438725.local
On the Reference Images for Yocto Project, the -<serial number> suffix has been added to the hostname on the version 5.4.0. Before that, use only the <family>-<processor>, and be aware that it does not work if more than one SoM is connected to the LAN, it will not work because both will have the same hostname.
The Username on the Board
The username is the name of the Linux user or the board, it should not be confused with the hostname!
Until embedded Linux BSP 2.8:
- Our Ångström-based LXDE demo image has default user configured as root and no password.
From embedded Linux BSP 3.0 onwards:
- Our Poky-based demo image 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.
- The torizon user has root privileges and you can execute
sudoandsujust like on a regular desktop Linux distro.
- The torizon user has root privileges and you can execute
Using the Visual Studio Extension for Torizon
Make sure to add your device first.
Then, on the Torizon Device Explorer, just right-click on your device and choose SSH Terminal option:
Using the Visual Studio Code Extension for Torizon
Make sure to add your device first.
Then, on the Torizon extension view, under Devices, choose your device and click the SSH Terminal button:
Passwordless SSH Configuration
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).
Check if You Already Have SSH Credentials Setup in Your Development PC
To check if you already have SSH credentials setup, run the following command:
$ ls $HOME/.ssh
Create SSH Credentials
If you already have files named id_rsa and id_rsa.pub you can skip this step, otherwise you have to create your security key 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:
...
Copy Credentials to the Target Device
Now you can copy the key to the target device, in other words, the Toradex SoM, 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.
$ ssh-copy-id torizon@192.168.1.114
If the method above won't work, you can copy the credentials manually. See the content hidden in the following collapsible section, if required:
Manually copy SSH credentials to the device
$ scp $HOME/.ssh/id_rsa.pub torizon@192.168.1.114:/home/torizon
torizon@192.168.1.114's password:
id_rsa.pub 100% 396 0.4KB/s 00:00
$ ssh torizon@192.168.1.114
torizon@192.168.1.114'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.
Validate That it Works
When you try to connect to the device you should be able to do it without typing the password:
$ ssh torizon@192.168.1.114
Last login: Fri May 3 09:35:43 2019 from 192.168.1.2
Troubleshooting
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
The command journalctl can be used to print log messages related to the ssh server:
# journalctl -u sshd*
Tips and Known Issues
This section provides insight about ssh configuration as well as known issues.
Password Authentication
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
Incompatible Cipher Support
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 root@192.168.10.2
ssh_packet_read: Connection closed
Looking more closely the following happens:
[user@host ~]$ ssh -v root@192.168.10.2
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 chacha20-poly1305@openssh.com <implicit> none
debug1: kex: client->server chacha20-poly1305@openssh.com <implicit> none
debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64
debug1: kex: curve25519-sha256@libssh.org 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 root@192.168.10.2
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: