1 - Foundation

Installating the Remote-SSH Extension

I opened VX Code and went to the Extensions panel (Ctrl+Shift+X). I searched for ‘Remote - SSH’ by Microsoft and clicked ‘Install’.

• Remote - SSH : connects to any SSH host
• Remote - SSH: Editing Configuration Files : gives me a UI to manage SSH config
• Remote - Explorer : sidebar panel to manage my remote connections

Connecting to Ubuntu VM

Right now I’m just setting everything up, so I will create an SSH-key with no passphrase.

SSH Keys

On my Windows PC, I ran the following on PowerShell:

ssh-keygen -t ed25519 -C "ansible-key" -f "c\users\nesto\.ssh\ansible_key"

When prompted for a passphrase, I pressed ‘Enter’ to skip it.

Copying the Public Key to Ubuntu

Now I need to put the public key on my VM. One way is to issue this PowerShell command:

type c:\users\nesto\.ssh\ansible_key.pub | ssh [email protected] "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys && chmod 700 ~/.ssh"

Then to test if it worked, I issued the following command from VS Code:

ssh -i ~/.ssh/ansible_key [email protected]

Disabling Password Authentication

Once key-based auth is confirmed working, I disable password SSH login on Ubuntu entirely.

sudo nano /etc/ssh/sshd_config

I find and change these lines:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

Then I restart SSH:

sudo systemctl restart ssh

Connecting via SSH-Remote

Now, back in VS Code, I pressed Ctrl+Shift+P to open the Command Palette and typed:

Remote-SSH: Connect to Host

It then asked for a host:

[email protected]

VS Code opened a new window, downloaded the VS Code Server onto the Ubuntu VM and connected. I now have a fully functional VS Code environment running on Ubuntu. I can open a terminal in VS Code and it drops me directly into a bash shell on the VM.

VS Code Extensions

Next, I installed some extensions on the remote host.

1. YAML (by Red Hat) - Almost everything in Ansible is YAML. This extension gives me syntax highlighting, schema validation, and auto-formatting for .yaml files. After installing it automatically validates Ansible playbooks against the Ansible YAML schema.

2. Ansible (by Red Hat) - This is purpose-built for Ansible work. It provides auto-completion for Ansible module names and parameters, definition for roles and variables, integration with ansible-lint, and syntax highlighting for Jinja2 expressions inside YAML files.

3. Python (by Microsoft) - Since Ansible is Python-based and I’ll be writing Python scripts alongside my playbooks, this is essential. It give sme IntelliSense, debugging, and virtual environment detection.

4. GitLens (by GitKaraken) - GitLens supercharges VS Code’s built-in Git support. Inline blame annotations that show me who last changed a line and when, directly in the editor. For a team environment, this is invaluable when tracking down who made a change to a playbook.

5. indent-rainbow - Ansible YAML is white-space sensitive. A misplaced indent breaks everything. This extension color codes indentation levels, making it immediately obvious when something is off.

6. Better Comments - Lets me color code comments in my playbooks.

Navigation

pwd                        # Print working directory — "where am I?"
ls -la                     # List all files including hidden ones, with permissions
cd /etc/ansible            # Change into a directory
cd ~                       # Go back to my home directory
cd ..                      # Go up one directory level

ls -la output explained:

The first column shows permissions (e.g. `-rw-r–r–). The 3rd and 4th columns show the owner and group. The last column is the filename.

File Operations

cp playbook.yml playbook.yml.bak     # Copy a file (useful before editing)
mv old_name.yml new_name.yml         # Rename or move a file
rm file.yml                          # Delete a file (no trash, gone forever)
mkdir -p roles/cisco_ios/tasks       # Create directories, including parents (-p)
cat inventory/hosts.yml              # Print file contents to terminal
less playbook.yml                    # Scroll through a file (q to quit)

Searching

grep -r "ios_config" ./playbooks/    # Search recursively for a string in files
grep -n "hostname" site.yml          # Show line numbers with matches
find . -name "*.yml"                 # Find all YAML files from current directory

grep -r "ios_config" ./playbooks/ command explained:

• r - means recursive (search all subdirectories too)
• "ios_config" - is the search term
• ./playbooks/ - is where to search.

File Permissions

Permissions matter most for 2 things in Ansible: SSH keys and vault password files. Both need to be readable only by me.

chmod 600 ~/.ssh/ansible_lab_key     # Owner read/write only — required for SSH keys
chmod 700 ~/.ssh/                    # Owner read/write/execute only — required for .ssh dir
chmod 644 playbook.yml               # Owner read/write, others read-only — normal for files
ls -la ~/.ssh/                       # Verify permissions look correct

Understanding chmod 600:

The 3 digits represent Owner, Group, Others. Each digit is a sum of read (4), write (2), and execute (1).

Keeping The System Updated

I set up a habit of running this at the start of any lab session:

sudo apt update && sudo apt upgrade -y

Here are the packages I install on any fresh Ubuntu VM that I’ll be using with Ansible:

sudo apt install -y \
    curl \
    wget \
    git \
    vim \
    nano \
    net-tools \
    openssh-server \
    python3 \
    python3-pip \
    python3-venv \
    tmux \
    tree \
    unzip

Home Directory Structure

When I log into my VM, I land in my home directory /home/nesto. This is my personal space on the system. Understanding how to organize it sets me up for clean Ansible project management.

What Lives Where

/home/ansible/               # My home directory (~)
├── .ssh/                    # SSH keys and known_hosts (always chmod 700)
│   ├── authorized_keys      # Public keys allowed to log in as me
│   └── known_hosts          # Fingerprints of hosts I've SSH'd to
├── .bashrc                  # Shell config, runs on every new terminal
├── .bash_profile            # Runs at login (not every terminal)
├── projects/                # Where I keep all my Ansible projects
│   └── ansible-network/     # My main project repo (covered in Part 4)
└── venvs/                   # Python virtual environments (covered in Part 3)
    └── ansible-env/

Key Directories

/etc/                        # System-wide configuration files
/etc/ansible/                # Default location for ansible.cfg (before project setup)
/usr/bin/                    # System executables (where 'ansible' binary lives after install)
/var/log/                    # System logs
/tmp/                        # Temporary files, cleared on reboot

tmux Concepts

• Session - a peristent workspace. It survives disconnects
• Window - like a tab inside a session. I can have multiple windows.
• Pane - a split within a window. I can have a playbook running in 1 pane and watch logs in another.

tmux Commands

tmux new -s ansible-lab         # Create a new session named "ansible-lab"
tmux attach -t ansible-lab      # Re-attach to an existing session
tmux ls                         # List all active sessions

Inside tmux all commands start with the prefix Ctrl+B:

Ctrl+B, d               # Detach from session (session keeps running)
Ctrl+B, c               # Create a new window
Ctrl+B, n               # Next window
Ctrl+B, p               # Previous window
Ctrl+B, "               # Split pane horizontally
Ctrl+B, %               # Split pane vertically
Ctrl+B, arrow keys      # Move between panes
Ctrl+B, z               # Zoom a pane to full screen (zoom again to restore)
Ctrl+B, [               # Enter scroll mode (use arrow keys, q to exit)

tmux Workflow

Every time I start a lab sessions I do this:

# Check if my session already exists
tmux ls

# If it does, attach to it
tmux attach -t ansible-lab

# If it doesn't, create it
tmux new -s ansible-lab

Inside the session I create 2 windows:

• Window 1 - Running playbooks
• Window 2 - Editing files, checking logs