Enable Communication Between GNS3 Appliances & The Host Machine (Ubuntu 24.04)

Recently, I set up a GNS3 server using an Ubuntu 24.04 VM to run and test my network emulations. While working on a project, I needed to establish an SSH connection between the host (the Ubuntu 24.04 server) and the virtual GNS3 appliances running inside it.

The basic network configuration was straightforward, and I could ping the devices just fine. However, I quickly hit a wall when trying to SSH into legacy appliances (like the Cisco C7200). Because modern Ubuntu 24.04 uses updated OpenSSH protocols, it actively rejects the older cryptographic algorithms offered by these legacy devices.

Getting this working required some specific SSH workarounds, so I decided to turn this into a runbook documentation for my future self—and for anyone else dealing with connection refused errors in their GNS3 labs.

Prerequisites

Before we jump into the SSH workarounds, make sure you have the base lab environment up and running:

• A Working GNS3 Server: For this guide, we are using an Ubuntu 24.04 host.

• A Connected GNS3 Client: Ensure your local client is successfully communicating with your GNS3 server.

• Working GNS3 Appliances: You will need at least one running legacy node to test the connection (e.g., a Cisco c7200 router).

Setting up The Topology

First, open your GNS3 client and create a new project. Drag and drop one or more routers (e.g., a Cisco c7200) from the Routers section into your workspace.

If you expect to connect more than one router to the host, grab an Ethernet switch from the Switches section and connect your routers to it.

Lastly, add a NAT node from the End Devices section. Connect this NAT node to your switch—or directly to your router if you are only testing a single device. This NAT node is crucial, as it acts as the bridge connecting your GNS3 lab to your Ubuntu host machine.

When you're done, you should have a topology that looks similar to mine, even if the exact layout isn't identical.

Device Configuration

Now it's time to configure the routers in our topology. To successfully connect to these devices from the Ubuntu host via SSH, we need to handle two main tasks on each router:

1. Configure an Interface with an IP: We need to assign an IP address to the interface connected to our NAT node/switch so it has a valid route to the host.

2. Configure SSH: We need to set up a local user, set a domain name, and generate the crypto keys required for the router's SSH service to start.

1. Configure an Interface with an IP

The NAT node we added earlier automatically acts as a DHCP server (managed by the Ubuntu host) for the devices connected to it. Because of this, we can simply configure the router's connected interface as a DHCP client.

Use the following commands in your router's console. Don't forget to replace the placeholder interface (<interface-id>) with the actual interface name used in your topology:

Router> enable
Router# configure terminal
Router(config)# interface <interface-id>
Router(config-if)# ip address dhcp
Router(config-if)# no shutdown
Router(config-if)# exit

To verify that the interface has successfully received an IP address from the NAT node, use the show ip interface brief command.

Depending on which mode you are currently in, use one of the following:

Router# show ip interface brief

or, if you are still in global configuration mode:

Router(config)# do show ip interface brief

Make a note of the assigned IP address (e.g., 192.168.122.X), as you will need it later when initiating the SSH connection from the Ubuntu host.

Before moving on to the SSH setup, let's verify that the Ubuntu host can actually reach the router. Open your Ubuntu 24.04 terminal and ping the IP address you just noted:

$ ping <interface-ip>

If you receive successful replies, your base networking is completely functional. Now that we know the host can speak to the device, it is time for us to configure SSH on the router.

2. SSH Configuration

Before we can enable SSH, we need to generate an RSA key pair. Cisco IOS uses a combination of the router's hostname and the IP domain name (e.g., R1.mydomain.com) to name these keys. Because of this, if you leave the hostname as the default ("Router") or forget to configure an IP domain name, the device will throw an error when you attempt to generate the keys.

Use the following commands to set the hostname, configure the domain name, and generate the RSA key pair. When prompted, enter 2048 for the modulus size:

Router(config)# hostname R1
R1(config)# ip domain-name mylab.local
R1(config)# crypto key generate rsa

Then change the default SSH version from 1.99 to 2 using the following command.

R1(config)# ip ssh version 2

Once the keys are generated and the SSH version is changed, we need to create a local user account and configure the VTY (Virtual Teletype) lines to accept SSH connections instead of Telnet.

R1(config)# username admin privilege 15 secret mypassword
R1(config)# line vty 0 4
R1(config-line)# login local
R1(config-line)# transport input ssh
R1(config-line)# exit

After that save your configuration using the following command.

R1(config)# do write

Issue: Legacy Cryptography vs. Modern OpenSSH

To see exactly what is causing the issue, try to SSH into the router from your Ubuntu host terminal. Use the following command, making sure to replace the placeholders with the actual username and IP address you configured in the previous steps:

$ ssh <username>@<router-interface-ip>

Instead of a password prompt, your Ubuntu host will immediately reject the connection and display an error message similar to this:

Unable to negotiate with 192.168.122.93 port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

This error is the root of the problem. Modern OpenSSH clients (like the one built into Ubuntu 24.04) have disabled these older SHA-1 key exchange methods by default due to known security vulnerabilities. However, legacy devices like our Cisco c7200 image only know how to communicate using these deprecated algorithms.

Solution: A Dedicated SSH Config File

You can bypass this error by chaining long flags to your SSH command, but that gets tedious. A cleaner, permanent fix is to use an SSH config file. We can configure Ubuntu to allow these legacy algorithms only when connecting to the GNS3 subnet (usually 192.168.122.*). This keeps your host machine secure for normal traffic while fixing your lab access.

Create a file named config in ~/.ssh/ using the following command:

$ nano ~/.ssh/config

Copy past the following lines into the configuration file:

Host 192.168.122.*
    # Re-enable legacy Key Exchange algorithms
    KexAlgorithms +diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha1
    
    # Re-enable legacy RSA signatures
    HostKeyAlgorithms +ssh-rsa
    PubkeyAcceptedKeyTypes +ssh-rsa
    
    # Re-enable legacy ciphers just in case the router demands them
    Ciphers +aes256-cbc,aes128-cbc,3des-cbc

Then save and exit the file before changing the file permissions using the following command:

$ chmod 600 ~/.ssh/config 

Now try connecting to the router again using the previous command:

$ ssh <username>@<router-interface-ip>

You should be able to connect to your router without any issues.

This is how you enable communication between GNS3 appliances & the host machine (Ubuntu 24.04). Please share and leave a comment if you find this guide helpful.

Now that your server is running and know how to establish SSH from the host machine, you might want to check out Step-by-Step: Configuring Route-Based IPsec VPNs on Cisco IOS.