Telnet capability?

[jdmcroy]

Has anyone ever explored adding telnet capability? http://localhost:222/telnet/...

[billchurch]

I've thought about it, and it seems like it would be possible... The one trick is authentication SSO, since telnet is pretty much free-form and you have to "expect" user and password and detect failures. There's not a standard around this so the solution would need to be flexible to account for differences in systems.

[billchurch]

This project seems promising for the node telnet-client. The front-end wouldn't need to change much, if at all.

https://github.com/mkozjak/node-telnet-client#readme

[jdmcroy]

Thanks for the link. That does look promising. I'll take a deeper look. It just seemed that based on the URL pattern (http://localhost:222/ssh/...) for web2ssh2 adding telnet would be a natural extension.

[billchurch]

Totally agree, and it looks like some of the logic for dealing with logging in, is handled by that project.

[cunningr]

Would love to see Telnet added. We would like to use this for managing network infrastructure and whilst SSH is the mainstay for networked connectivity, no-net connectivity via a terminal server and reverse telnet still seems to be the most common mode of access.

[lpiskuno]

telnet could be added and not to worry about authentication. I think just opening session and provide user with the login prompt would be sufficent

[billchurch]

Telnet Capability - Future Enhancement Requirements

Great suggestion! Adding Telnet support would extend WebSSH2's capabilities beyond SSH. Here are the comprehensive requirements for implementing Telnet functionality:

Architecture Overview

WebSSH2 would become a multi-protocol terminal gateway:

• /ssh/host/:host - SSH connections (existing)
• /telnet/host/:host - Telnet connections (new)

Technical Requirements

1. Telnet Protocol Implementation

Option A: Use Existing Library

// Using 'telnet-client' npm package
import TelnetClient from 'telnet-client';

const telnet = new TelnetClient();
await telnet.connect({
  host: '192.168.1.1',
  port: 23,
  timeout: 15000
});

Option B: Native Implementation

// Using Node.js net module for raw telnet
import net from 'net';

class TelnetConnection {
  constructor() {
    this.socket = new net.Socket();
    this.negotiateOptions();
  }
  
  negotiateOptions() {
    // Implement telnet option negotiation (RFC 854)
    // IAC WILL/WONT/DO/DONT sequences
  }
}

2. Routing Structure

// New telnet routes
app.get('/telnet', telnetIndex);
app.get('/telnet/host/:host', telnetConnect);

// WebSocket handling
io.on('connection', (socket) => {
  const protocol = socket.handshake.query.protocol;
  if (protocol === 'telnet') {
    handleTelnetConnection(socket);
  } else {
    handleSSHConnection(socket);
  }
});

3. Configuration Schema

{
  "telnet": {
    "enabled": true,
    "port": 23,
    "timeout": 30000,
    "term": "vt100",
    "negotiateOptions": {
      "ECHO": true,
      "SGA": true,
      "NAWS": true,
      "TERMINAL_TYPE": true
    },
    "allowedHosts": ["192.168.1.0/24"],
    "blockedHosts": [],
    "encoding": "utf8"
  }
}

4. Connection Handler

class TelnetConnectionHandler {
  constructor(socket, config) {
    this.socket = socket;
    this.config = config;
    this.telnet = null;
  }

  async connect(host, port, options) {
    // Establish telnet connection
    // Handle authentication if needed
    // Set up data proxying
  }

  handleData(data) {
    // Process telnet commands
    // Handle special sequences
    // Forward to client
  }

  handleClientInput(input) {
    // Process client input
    // Send to telnet server
  }
}

Security Considerations

⚠️ CRITICAL SECURITY WARNINGS

1. No Encryption: Telnet transmits everything in plaintext
2. Credential Exposure: Passwords are visible in network traffic
3. Man-in-the-Middle: No protection against MITM attacks
4. Network Sniffing: All data can be captured

Security Mitigations

// Mandatory security warnings
const TELNET_WARNING = `
⚠️ WARNING: Telnet is INSECURE!
- All data, including passwords, is transmitted in plain text
- Use SSH instead whenever possible
- Only use Telnet on trusted, isolated networks
`;

// Configuration restrictions
{
  "telnet": {
    "requireExplicitConsent": true,
    "showWarningBanner": true,
    "allowOnlyLocalNetwork": true,
    "requireHTTPS": true,  // At least encrypt browser->server
    "sessionTimeout": 300000  // 5 minutes
  }
}

Implementation Phases

Phase 1: Basic Telnet Support

• Implement basic telnet connection
• Text input/output only
• No option negotiation
• Security warnings

Phase 2: Full Protocol Support

• Complete RFC 854 implementation
• Option negotiation (WILL/WONT/DO/DONT)
• Terminal type negotiation
• Window size negotiation

Phase 3: Advanced Features

• Authentication handling
• Character set negotiation
• Binary mode support
• Line mode vs character mode

User Interface Changes

// Connection type selector
<select id="protocol">
  <option value="ssh">SSH (Secure)</option>
  <option value="telnet">Telnet (INSECURE)</option>
</select>

// Warning modal for Telnet
if (protocol === 'telnet') {
  showSecurityWarning({
    title: 'Insecure Connection',
    message: 'Telnet is unencrypted. Continue?',
    requireConfirmation: true
  });
}

Testing Requirements

1. Protocol Tests

   • Connection establishment
   • Option negotiation
   • Data transmission
   • Special character handling

2. Compatibility Tests

   • Various telnet servers
   • Network devices (routers, switches)
   • Legacy systems
   • Different terminal types

3. Security Tests

   • Warning display verification
   • Network restriction enforcement
   • Session timeout

Documentation Needs

1. Security Guide (MANDATORY)

   • Clear warnings about telnet insecurity
   • When NOT to use telnet
   • Network isolation requirements

2. Configuration Guide

   • Telnet-specific settings
   • Host restrictions
   • Terminal configuration

3. Migration Guide

   • Moving from telnet to SSH
   • Alternative secure solutions

Alternative Approaches

Instead of Telnet, consider:

1. SSH everywhere: Help users enable SSH on their devices
2. VPN + Telnet: Use VPN for encryption, then telnet locally
3. SSH Tunneling: Tunnel telnet through SSH
4. Serial over IP: For device management

Estimated Effort

• Basic Implementation: 1-2 weeks
• Full Protocol Support: 2-3 weeks
• Security & Documentation: 1 week
• Testing: 1 week

Libraries to Consider

• telnet-client - Full-featured client
• node-telnet-client - Promise-based
• Native net module - For custom implementation

Final Recommendation

While technically feasible, adding Telnet support requires careful consideration of security implications. Any implementation MUST include prominent security warnings and should encourage users to use SSH instead.

This is marked as a future enhancement. Community contributions are welcome, but must include comprehensive security documentation and warnings.

References

• RFC 854 - Telnet Protocol
• RFC 855 - Telnet Option Specifications
• Telnet Security Issues