The HP 1910 hides its own CLI: recovering and deploying a JG348A

The HP 1910-8G is sold as a web managed switch. The web UI is what you are meant to use, and it is fine for a flat network with a handful of ports.

It is also a Comware switch with a complete CLI inside it, deliberately hidden behind an undocumented command. Once you know that, an inexpensive eight-port box becomes something you can configure like any other Comware device: trunks, hybrid ports, SSH, a dedicated management VLAN, the lot.

This is the write-up of taking one from nobody knows the password to a production access switch.

The hardware#

• Model: HP 1910-8G (JG348A)
• Software: Comware 5.20, Release 1111P02
• Management: console, HTTPS, SSH

Comware 5 matters more than it looks. It shapes the whole second half of this article, because its cryptography predates everything a current SSH client is willing to negotiate by default.

Password recovery#

The previous administrator's credentials were unknown, and there is no reset button that preserves configuration. Recovery goes through BootROM:

1. Connect a console cable. This cannot be done over the network, which is the point. 2. Reboot and interrupt startup with Ctrl+B to enter BootROM. 3. Choose the password-recovery option. 4. Skip the startup configuration. 5. Boot into defaults.

You land here:

<HP 1910 Switch>

Worth being clear about what this means for your own physical security. The recovery procedure is not a flaw, it is the documented vendor process, and every managed switch has an equivalent. But it means console access is administrative access. A switch in an unlocked comms cupboard has no password, regardless of what you set. Physical security is the control here; the password is not.

The CLI is there, it is just hidden#

Straight after boot you get a deliberately reduced command set:

summary
ipsetup
password
ping
reboot

No system-view, no interface, no vlan. That is the web-managed product tier doing its job.

The full Comware CLI is unlocked with an undocumented command and a fixed vendor password, both of which have been public knowledge for over a decade and appear in HP's own community forums:

_cmdline-mode on

512900

That password is identical on every unit of this model. Treat it as obfuscation, not as a security control. It stops a casual user wandering into system-view, and it stops nobody else. After it, you have the real thing:

system-view
display current-configuration
interface
vlan
ssh
snmp

Base configuration#

Hostname, and a management VLAN that is deliberately not VLAN 1:

system-view

sysname ACCESS-SW-01

vlan 99

 name SW_MGMT

Give the management VLAN an interface and a default route:

interface Vlan-interface99
 ip address 192.0.2.10 255.255.255.0

ip route-static 0.0.0.0 0.0.0.0 192.0.2.1

Management on its own VLAN rather than VLAN 1 is worth the two extra minutes. VLAN 1 is where every unconfigured port lands by default, so management living there means anything plugged into an unprovisioned port shares a broadcast domain with the switch's own control plane.

A local account#

local-user netadmin
 password
 authorization-attribute level 3
 service-type lan-access
 service-type ssh terminal

Level 3 is full administrative access on Comware 5. If you have anyone who needs to look but not touch, give them a lower level rather than sharing this one.

SSH, and why your client will refuse it#

Enable the server and generate host keys:

ssh server enable

public-key local create rsa

user-interface vty 0 15
 authentication-mode scheme
 protocol inbound ssh
 idle-timeout 120 0

Then a current OpenSSH client will fail to connect, and the error will not be especially clear about why.

Comware 5 offers only algorithms that modern clients disabled on purpose:

Every one of those is deprecated for a reason. diffie-hellman-group1-sha1 is 1024-bit and considered breakable by a well-resourced attacker. CBC-mode ciphers in SSH have known plaintext-recovery weaknesses. SHA-1 is broken for collisions. ssh-rsa here means RSA with SHA-1 signatures, which is why OpenSSH 8.8 stopped accepting it by default.

You can re-enable them per connection:

ssh -o KexAlgorithms=+diffie-hellman-group14-sha1 -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa -o MACs=hmac-sha1 -o Ciphers=aes128-cbc netadmin@192.0.2.10

Two things to be deliberate about.

Ask for the least-bad option first. The command above requests diffie-hellman-group14-sha1 (2048-bit) and aes128-cbc, not diffie-hellman-group1-sha1 and 3des-cbc. The switch will accept whichever you offer, so offer the better one.

Do not put this in your global SSH config. It is tempting to add these options to ~/.ssh/config under Host * and stop thinking about it. That silently weakens every SSH connection you make, including to servers that support modern algorithms, and downgrade protection is precisely what those defaults exist to provide. Scope it to the host:

Host access-sw-01
    HostName 192.0.2.10
    User netadmin
    KexAlgorithms +diffie-hellman-group14-sha1
    HostKeyAlgorithms +ssh-rsa
    PubkeyAcceptedAlgorithms +ssh-rsa
    MACs hmac-sha1
    Ciphers aes128-cbc

The honest conclusion: on hardware this old the management transport is weak no matter how you configure it. The compensating control is network design: keep the management VLAN unreachable from user VLANs, and treat "reachable from a user port" as the thing you actually defend.

HTTPS has the same problem for the same reason, and is enabled with:

ip https enable

An idle SSH session that kept dropping#

Sessions died after a period of inactivity. I spent a while suspecting idle-timeout on the VTY lines.

It was the client. Tabby's keepalive settings were leaving the connection idle long enough to be dropped; PuTTY against the same switch, in the same session, stayed up. Adjusting Tabby's keepalive fixed it.

The generalisable bit: when two clients behave differently against one server, the server is not the variable. I could have read that from the evidence sooner than I did.

VLANs and ports#

The real deployment carried about two dozen VLANs, since the switch had to trunk everything the upstream network carried. The pattern is what transfers, so here is a reduced example.

vlan 2
 name ADMIN

vlan 102
 name DATA

vlan 104
 name PRINTERS

vlan 130
 name VOICE

Access ports for single-purpose devices:

interface GigabitEthernet1/0/1
 port link-type access
 port access vlan 2

The uplink, carrying everything to the core:

interface GigabitEthernet1/0/8
 port link-type trunk
 port trunk permit vlan all

permit vlan all is convenient and blunt. It is the right call when this switch must carry whatever the core carries and the VLAN list changes without warning. It is the wrong call if you want the uplink to enforce anything, because an explicit list is a control and all is a decision not to have one. I chose convenience knowingly.

The hybrid port that keeps VLAN 1#

The interesting configuration is a desk port serving a PC and an IP phone: data untagged, voice tagged, one cable.

interface GigabitEthernet1/0/3
 port link-type hybrid
 port hybrid vlan 102 untagged
 port hybrid vlan 130 tagged

Check it and you find something you did not ask for:

port hybrid vlan 1 102 untagged

VLAN 1 is still there. Every hybrid port starts as an untagged member of VLAN 1, and adding VLAN 102 adds to that membership rather than replacing it. Nothing warns you. The port works, the phone works, the PC works, and all the while the port is quietly bridging VLAN 1 to a desk, which is the VLAN every unconfigured device on the network lands in.

Remove it explicitly:

 undo port hybrid vlan 1

Final:

interface GigabitEthernet1/0/3
 port link-type hybrid
 undo port hybrid vlan 1
 port hybrid vlan 130 tagged
 port hybrid vlan 102 untagged

This is the one thing on this page I would call a genuine trap. Access ports replace their VLAN membership; hybrid ports accumulate it. If you carry the access-port mental model across, you will leave VLAN 1 on every voice port you build and never see a symptom.

Resulting layout#

Verify, then save#

Do not trust that a command applied because it did not error.

display current-configuration

display vlan

display interface GigabitEthernet1/0/8

display ip interface brief

display ssh server status

display users

display logbuffer

display vlan is the one that would have caught the VLAN 1 problem immediately - it lists membership per VLAN, so a port appearing under VLAN 1 that has no business being there is visible at a glance.

Then save, because Comware does not:

save

What I would tell myself before starting#

The product tier is a marketing decision, not a technical one. The full CLI was in the box the whole time. Worth asking of any "simplified" device before assuming a limitation is real.

A fixed vendor password on every unit is not security. _cmdline-mode keeps casual users out of system-view. It has never kept anyone else out of anything.

Hybrid ports accumulate VLAN membership. Check for VLAN 1 every time.

Legacy crypto compatibility should be scoped to the host that needs it, never added globally. The workaround is a real cost, and it should be paid only where it is genuinely owed.

Old management planes are defended by network design, not by their own settings. SHA-1 and CBC are what this switch has. Deciding who can reach the management VLAN is the part still under your control.

The result is a reusable baseline: recovered, on a dedicated management VLAN, SSH and HTTPS up, trunk and hybrid ports configured, verified against display current-configuration rather than against optimism, and saved.