Confirm that you set the key up correctly by navigating to the VSCode terminal again and running: ssh -T git@gitlab.cs.washington.edu. Respond with yes to adding GitLab as a known host. You should see Welcome to GitLab as a response. SSH, or secure shell, is an encrypted protocol used to administer and communicate with servers. When working with a CentOS server, chances are, you will spend most of your time in a terminal session connected to your server through SSH. In this guide, we’ll focus on setting up SSH keys for a vanilla CentOS 7 installation.

5 minute read

This chapter will explain how to install mcx-python. Please select the operating system you are u using:

Vectioneer uses CMake (https://cmake.org/) as its main tool for building, testing and deploying software. Also MOTORCORTEX itself is built using CMake. CMake is widely accepted and supported by many IDEs, which means that the user is free to choose his/her own development environment.

To make things more convenient, Vectioneer has developed plugins for CLion (https://www.jetbrains.com/clion). CLion is an advanced Integrated Development Environment that has many tools that makeprogramming easy, is available across platforms and is capable to cross-compile and deploy MOTORCORTEX applications straight to the controller with a click of a button. This section is a guide, how to install CLion and the MOTORCORTEX plugins from the CLion Marketplace and get started quickly with developing MOTORCOREX applications.

Installing CLion can be done by downloading Clion from the website Download CLion from: https://www.jetbrains.com/clion/download;

Or running the following command.

After installing Clion you will have to install the MOTORCORTEX Templates plugins.

In the Main Menu open: File → Settings, then find the Plugins menu.

In the search section type motorcortex, then click Install.

There are two possibilities to develop MOTORCORTEX applications:

• Use remote development and compile the application on theMOTORCORTEX Target System;
• cross-compile on your development PC and deploy the executable to theMOTORCORTEX Target System

The first method is easy to set up, it does not require additional dependencies however the downside is that a compile time for the large projects may be significant. The second method overcomes this problem, but requires a cross-compilation tool-chain to be set up.

Setting up remote development in CLion

In the Main Menu open File → Settings find the Toolchains menu.

Select Environment type: Remote Host. Enter the remote host credentials and press OK, wait for a few seconds to let CLion find all the necessary tools.

The remote toolchain will now be ready to use.

Setting up cross-compilation in CLion (Linux)

Download the development toolchain from our public git repository:

Click on Downoad.

Extract downloaded archive to the local folder. Open the Terminal and execute:

Enter the target directory where to install the SDK to. It is a good idea to keep the SDK in the home folder, where administrative rights are not required: (for example ~/mcx-sdk):

Start CLion and install the MOTORCORTEX Toolchain plugin. To install the plugin, open File → Settings → Plugins. Then, in the Marketplacesection, type motorcortex. Install the plugin and restart CLion.

Before working with a remote MOTORCORTEX host, make sure that the host is connected and reachable.

Clion Ssh Key Centos

Use ssh-copy-id to provide a temporary access without a password tothe remote MOTORCORTEX host.

If there is an error: No identities found, run the following command

to generate a new key pair and run the ssh-copy-id command again.

Open Terminal and create a folder to mount the remote MOTORCORTEX file system on.

Mount MOTORCORTEX file system with the following command:

⚠ Note that you need to execute this last command every time after you logout or reboot your development system.

Configure the compiler paths to use the MOTORCORTEX cross-compilation toolchain.

Open File → Settings → Build Execution Deployment → Toolchains.

Create a new System Toolchain with the name motorcortex.

Fill in Make, C Compiler and C++ Compiler paths to point the MOTORCORTEX SDK as shown below.

Configure sysroot path to use the latest MOTORCORTEX libraries from theremote host.

Open File → Settings → Build, Execution, Deployment → **Motorcortex SDK and fill in the path to the mounted folder (mcx-sysroot) in the field “Sysroot path”. The other field on this screen are left empty.

Add the connection to the remote MOTORCORTEX host. Open Tools → Deployment → Configuration, add a new SFTP connection and fill in the details (see below). Press the Test Connection button to make sure that the filled data is correct. Press the Autodetect button to set the root path. Uncheck the Visible only for this project checkbox make this host visible in all the projects.

Cross-compiling MOTORCORTEX applications.

In CLion open the project configuration menu.

Click on + and select Motorcortex Remote Application. In the deployment profile field select MOTORCORTEX remote host.

In the Run/Debug configuration select the just created cross-compiled application with CrossRelease or CrossDebug build profile. Press the hammer button to cross-compile, play to copy and run on the remote MOTORCORTEX host and the bug button to start a remote debug session.

Deployment and Auto-start of applications.

Alternative build environments and IDEs

Since the MOTORCORTEX development environment uses CMake as its main tool, development can also easily be setup in other IDEs like Eclipse, NetBeans or Microsoft Visual Code. Also CMake can be used from the command line if one wishes. Refer to your IDE’s documentation on how to setup your environment to work with CMake. Code can always be compiled on the Vectioneer Linux Target System, sincethat has everything on-board to compile MOTORCORTEX projects. In general you can build the application by using the default vuild method of clion:

Copy your project onto the Target System (e.g. /home/admin/myProject/).

Then login to the Target system via SSH (on a Windows system you can use Putty).

Navigate to the Project folder:

Make an empty build folder and enter it:

Run cmake, compile and install:

SSH, or Secure Shell, is a very common way to securely access remote machines, typically via the command line. It aims at ensuring that your connection, and therefore all data passed, is free from eavesdropping. Because of this, there are quite a few checks built-in to the popular SSH clients, like OpenSSH, that ensure your connection can't be compromised.

An example of one of these checks is the following, which identifies when the fingerprint of a server has changed:

When you connect to a server via SSH, it gets a fingerprint for the ECDSA key, which it then saves to your home directory under ~/.ssh/known_hosts. This is done after first connecting to the server, and will prompt you with a message like this:

If you enter 'yes', then the fingerprint is saved to the known_hosts file, which SSH then consults every time you connect to that server.

But what happens if a server's ECDSA key has changed since you last connected to it? This is alarming because it could actually mean that you're connecting to a different server without knowing it. If this new server is malicious then it would be able to view all data sent to and from your connection, which could be used by whoever set up the server. This is called a man-in-the-middle attack. This scenario is exactly what the 'WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!' message is trying to warn you about.

Of course, this isn't always the case, and there are many reasons for the ECDSA key fingerprint to change for a server. In my case, I had an elastic IP address on AWS and assigned it to a different server after redeploying our application. The IP address and hostname I was connecting to were the same, but the underlying server was different, which is what tripped the SSH client to issue this warning.

Fixing the Issue

If you are 100% sure that this was expected behavior and that there is no potential security issue, you'll need to fix the issue before continuing.

The easiest ways I've found to fix this problem is the following two solutions.

Manually Resolve via known_hosts

• In the warning message find the line that tells you where the offending ECDSA key is located in the known_hosts file. In my example this line said 'Offending ECDSA key in /Users/scott/.ssh/known_hosts:47', which refers to line 47.
• Open the known_hosts file specified in the warning message
• Delete the line specified in the warning message

By deleting this line, your SSH client won't have an ECDSA key fingerprint to compare to, and thus will ask you again to verify the authenticity of the server the next time you connect. Once done, you'll have a new fingerprint in our known_hosts file for this server, and the warning will be gone.

Resolve Using ssh-keygen

Clion Ssh Key Ubuntu

Another solution would be to use the ssh-keygen utility to delete the offending key from your known_hosts file, which can be done with the following command:

Clion Ssh

So in my example I'd use it like this:

Clion Set Ssh Key

This method is good if you don't want to manually alter the known_hosts file yourself, and the utility is easier to use if you have multiple hostnames and IP addresses to fix. It can also handle hashed hostnames in a known_hosts.old file.