Guided buildcore7 steps~20 min3 devices

Lock management down to SSH

Make a switch manageable from the admin subnet, then harden it: RSA keys, SSH version 2, a local account, and VTY lines that refuse everything but SSH.

What you'll be able to do: An access switch that the admin PC can reach from its own subnet, whose remote-access lines accept only SSH version 2 with a local account — the baseline every managed device should ship with.

Start this build in the lab

Topics: SSH · Network security · Default gateway

What you'll build

Edge — a router, the router between the admin subnet and the switch's management subnet
SW-Floor — a switch, the access switch you are hardening
PC-Admin — a pc, the network team's admin workstation

Step by step

1. Set up the admin subnet
Network teams manage devices from a subnet of their own. Drag a router and a PC onto the canvas, cable the PC's Eth0 to the router's Gi0/1, and address both: the router is 10.20.0.1, the admin PC 10.20.0.10 with the router as its gateway.
- Cable PC-Admin Eth0 ↔ Edge Gi0/1
On Edge — Name the router and address the admin-facing port
```
enable
configure terminal
hostname Edge
interface Gi0/1
ip address 10.20.0.1 255.255.255.0
no shutdown
exit
end
```
On PC-Admin — Name the admin PC and address it
```
hostname PC-Admin
ipconfig Eth0 10.20.0.10 255.255.255.0 10.20.0.1
```
Check: run show ip interface brief on Edge and look for Gi0/1 10.20.0.1 YES manual up up.
Why: Keeping management traffic on its own subnet means an ACL can later say 'only 10.20.0.0/24 may log in' in one line. Everything after this step is about who can reach the switch, so start by deciding where the admins sit.
2. Cable the switch you will manage
Drag a switch on, name it SW-Floor, and cable the router's Gi0/0 to the switch's Gi0/1. Give Gi0/0 192.168.99.1/24: that subnet is where the switch's own management address will live.
- Cable Edge Gi0/0 ↔ SW-Floor Gi0/1
On Edge — Address the port toward the switch's management subnet
```
enable
configure terminal
interface Gi0/0
ip address 192.168.99.1 255.255.255.0
no shutdown
exit
end
```
On SW-Floor — Name the switch
```
enable
configure terminal
hostname SW-Floor
end
```
Check: run show ip route on Edge and look for C 192.168.99.0/24 is directly connected, Gi0/0.
Why: A switch forwards frames without any IP address at all. The address you are about to give it is not for forwarding — it is purely so you can reach the switch itself.
3. Give the switch an address — and find it half-reachable
Put 192.168.99.2 on the switch's VLAN 1 interface and bring it up. Edge can ping it now. PC-Admin cannot: the ping reaches the switch, but the reply is for a host on another subnet and the switch has no idea where to send it.
On SW-Floor — Create the management interface
```
enable
configure terminal
interface vlan 1
ip address 192.168.99.2 255.255.255.0
no shutdown
exit
end
```
On PC-Admin — Try to reach the switch from the admin subnet
```
ping 192.168.99.2
```
Check: run show ip interface brief on SW-Floor and look for Vlan1 192.168.99.2 YES manual up up.
Why: A switch that is not routing behaves like a host: it can answer its own subnet directly, but a reply to anywhere else needs a gateway, and a switch has none until you give it one.
4. Give the switch a way home
ip default-gateway 192.168.99.1 is the switch's equivalent of the gateway on a PC: every reply to a subnet it does not know goes to Edge. Ping again from PC-Admin and the switch answers.
On SW-Floor — Point the switch's own traffic at the router
```
enable
configure terminal
ip default-gateway 192.168.99.1
end
```
On PC-Admin — The same ping, now that replies can find their way back
```
ping 192.168.99.2
```
Check: run show running-config on SW-Floor and look for ip default-gateway 192.168.99.1.
Why: Remote management is a two-way conversation. A device you can reach but that cannot answer you is, for an admin, the same as a device that is down.
5. Give SSH an identity: domain, keys, version 2
SSH encrypts the session with an RSA key pair, and the key is named hostname.domain — so the domain name goes in first. Generate a 2048-bit key, then insist on SSH version 2. show ip ssh flips from Disabled to Enabled the moment the key exists.
On SW-Floor — Set the domain, generate the RSA key pair, and require SSH version 2
```
enable
configure terminal
ip domain-name netforge.lab
crypto key generate rsa modulus 2048
ip ssh version 2
end
```
Check: run show ip ssh on SW-Floor and look for SSH Enabled - version 2.0.
Why: Telnet sends every keystroke, passwords included, in clear text; SSH encrypts the whole session. Version 1 has known weaknesses, so a hardened device speaks version 2 only.
6. Create the accounts SSH will check
SSH logs in a user, not a shared line password, so create one: netadmin, at privilege 15 so it lands straight in privileged mode. Protect privileged mode on the console too, with an enable secret.
On SW-Floor — A local admin account and a secret for privileged mode
```
enable
configure terminal
username netadmin privilege 15 secret Forge-Admin-26
enable secret Forge-Enable-26
end
```
Check: run show running-config on SW-Floor and look for username netadmin privilege 15 secret Forge-Admin-26.
Why: Named accounts mean every change can be traced to a person, and one leaver's access can be removed without re-keying everyone. Real gear stores a secret only as a hash; this lab prints it as you typed it, so read that line as 'a secret is set', not as what a real config shows.
7. Lock every remote line to SSH, then save
A switch has sixteen remote-access lines, 0 to 15, so configure all of them at once. login local checks the netadmin account, transport input ssh refuses Telnet outright, and exec-timeout 5 0 logs out a session left idle for five minutes. The lab checks this configuration line by line — it does not run a real SSH session — so save it and read it back.
On SW-Floor — SSH-only, locally authenticated, auto-logout on every VTY line; then save
```
enable
configure terminal
line vty 0 15
login local
transport input ssh
exec-timeout 5 0
end
copy running-config startup-config
```
Check: run show running-config | section line on SW-Floor and look for line vty 5 15.
Why: Without transport input ssh the lines still accept Telnet, and without login local they fall back to a shared line password or no login at all. Securing only lines 0 to 4 is a classic miss: lines 5 to 15 stay open for whoever finds them.

The theory behind it

Let the router hand out the addresses — Build a four-device office LAN, address one PC by hand, then put a DHCP pool on the router so the next machine configures itself.
One DHCP server for every floor — Serve a user floor from a central DHCP server on another subnet — watch the first request die at the router, then relay it with ip helper-address.
Let the core switch hand out the addresses — Run two department VLANs, their gateways and their DHCP pools on a single switch — and find out why a perfect pool can still hand out nothing.
NAT to the internet — Hide two private office LANs behind the single public address your provider gave you.
Give the whole network one clock — Build an NTP hierarchy from HQ to a branch switch, read the strata hop by hop, then find the security ACL that silently broke time while ping kept working.

Build it for real

The lab walks you through these steps and ticks each one off as your network starts working.

Open in the lab

What you'll build

Step by step

1. Set up the admin subnet

2. Cable the switch you will manage

3. Give the switch an address — and find it half-reachable

4. Give the switch a way home

5. Give SSH an identity: domain, keys, version 2

6. Create the accounts SSH will check

7. Lock every remote line to SSH, then save

The theory behind it

More in Network services

Build it for real