Search by Tags

SSH

 
Applicable for

Compare with Revision

Subscribe for this article updates

Establishing an SSH Connection

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.

E.g. by using the Linux command line ssh client 'ssh' one can establish a connection as follows:

[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:~#

On Windows hosts putty is a commonly used ssh client.

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*

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  none
debug1: kex: client->server chacha20-poly1305@openssh.com  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:

https://bbs.archlinux.org/viewtopic.php?id=199640