The "Permission denied" error when SSHing into a Cisco virtual router in GNS3 usually stems from missing or incorrect authentication credentials rather than network connectivity issues. This specific SSH failure indicates that the server accepted the connection but rejected the provided username or password. To resolve this, you must verify the local user configuration on the virtual device and ensure your client is sending the correct keys or passwords.
Verifying Virtual Router Authentication Settings
The most common cause for this error in a lab environment is that the virtual router has not been configured with a local user account that matches the credentials you are attempting to use. Unlike physical hardware where default credentials might be printed on a label, virtual devices often start with a clean configuration or require explicit setup of administrative access.
When you open the CLI of your Cisco virtual router (such as an IOSv or CSR1000v), you need to check if a local user exists. If no user is defined, any SSH attempt will fail immediately because there is no account to authenticate against. You should enter global configuration mode and create a user with at least secret privileges. The command structure typically involves setting a username and assigning a secret password that is encrypted. For example, using
username admin privilege 15 secret mypassword creates an admin user with full privileges. Without this step, the SSH daemon has no valid identity to verify against.
It is also crucial to ensure that the line vty configurations allow login via password or key. If the lines are configured to only accept public-key authentication but you are providing a password, or vice versa, the connection will be denied. Check the
line vty 0 4 section to see if
login local or
transport input ssh is present. Misalignment between the authentication method on the server and the client is a frequent source of confusion.
Checking GNS3 Node Configuration
GNS3 provides a graphical interface to manage node settings, which can sometimes override or conflict with CLI configurations if not set up correctly. When you first add a new router to your topology, GNS3 may prompt you to set initial credentials. If these were left blank or set incorrectly, the node might boot with a configuration that does not match your expectations.
Navigate to the node properties in the GNS3 GUI and inspect the "Startup Config" tab. If you are using a custom image or a pre-configured box, ensure that the startup config file actually contains the
username and
enable secret commands. Sometimes, users export a running config from one device and import it into another, forgetting to update the credentials for the new instance. This results in a mismatch where the router expects one password, but the GNS3 console or SSH client tries another.
Additionally, verify that the node is fully booted before attempting SSH. Cisco virtual routers can take several minutes to initialize their services, including the SSH daemon. Attempting to connect while the system is still loading processes can lead to unstable connections or authentication failures. Look for the
Router# prompt in the console window to confirm the device is ready.
SSH Client and Key Management
If your credentials are correct, the issue might lie with how your SSH client handles keys or host verification. Linux systems, which are commonly used to run GNS3, often have strict SSH policies. If you are using key-based authentication, ensure that the private key you are passing is accessible and has the correct permissions. A common mistake is having a private key file with world-readable permissions, which OpenSSH will refuse to use for security reasons.
You can test the connection with verbose output to see exactly where it fails. Running
ssh -v admin@ provides detailed logs of the negotiation process. This output will tell you if the server is rejecting the key format, if the password is wrong, or if there is a protocol mismatch. This diagnostic step is invaluable for pinpointing whether the problem is local to your machine or remote on the router.
For those experiencing broader connectivity issues, such as bad IP addresses or hostname resolution errors, refer to our guide on
Troubleshooting SSH Connection Issues on Linux: Router Outputs 'Bad IP Address or Host Name'. This resource covers network layer problems that might precede authentication failures.
Firewall and Network Permissions
While less common for local virtual networks, firewall rules on your host machine can sometimes interfere with SSH traffic. Ensure that your local firewall allows outbound SSH connections on port 22. In some enterprise environments or restricted setups, outbound traffic might be blocked, leading to timeouts that can be misinterpreted as permission errors if the connection drops during the handshake.
Furthermore, check if the virtual network adapter in GNS3 is correctly bridged or NATed. If the router's management interface is not reachable via ICMP ping, SSH will certainly fail. Use
ping from your host terminal to the router's management IP address. If ping fails, focus on network configuration and interface status rather than SSH credentials.
For scenarios involving WSL or other virtualized environments connecting to local resources, see
How to connect to a local machine from WSL? for insights on network isolation and connectivity troubleshooting.
Frequently Asked Questions
Why does SSH work with Telnet but not SSH?
Telnet often uses simpler authentication methods or may be configured to allow empty passwords in older IOS versions, whereas SSH enforces stricter security policies. Ensure that your SSH configuration explicitly enables password authentication or key exchange if Telnet succeeds without them.
Can I reset the password of a GNS3 router if I am locked out?
Yes, you can reboot the node and interrupt the boot process to access ROMMON mode, allowing you to bypass the startup config. Alternatively, if you have console access, you can manually edit the startup config file in the GNS3 project directory to remove or change the username entries before reloading.
What is the default SSH port for Cisco virtual routers?
The default SSH port is 22. If your router has been configured to use a non-standard port, you must specify it in your SSH command using the
-p flag, such as
ssh -p 2222 admin@ip_address.
How do I fix key permission errors on Linux?
SSH requires private keys to have restricted permissions, typically 600. Use the command
chmod 600 ~/.ssh/id_rsa to restrict access to the owner only. This prevents OpenSSH from refusing to use the key due to security concerns.
Is it safe to disable SSH host key checking in GNS3 labs?
Disabling host key checking (
-o StrictHostKeyChecking=no) can simplify lab workflows by avoiding repeated prompts for unknown hosts. However, this reduces security against man-in-the-middle attacks, so it should only be done in isolated, trusted lab environments.