fatedier/frp · error

generate random id error: %v

Error message

generate random id error: %v

What it means

Emitted when util.RandIDWithLen(8) fails while generating a random proxy name for an SSH tunnel whose --name flag was omitted (default name becomes sshtunnel-<type>-<random8>). RandIDWithLen reads from crypto/rand, so failure means the system entropy source is unavailable — an extremely rare condition on healthy hosts.

Source

Thrown at pkg/ssh/server.go:298

		return nil, nil, helpMessage, fmt.Errorf("new proxy configurer error")
	}
	config.RegisterProxyFlags(cmd, pc, config.WithSSHMode())

	clientCfg := v1.ClientCommonConfig{}
	config.RegisterClientCommonConfigFlags(cmd, &clientCfg, config.WithSSHMode())

	cmd.InitDefaultHelpCmd()
	if err := cmd.ParseFlags(args); err != nil {
		if errors.Is(err, flag.ErrHelp) {
			helpMessage = cmd.UsageString()
		}
		return nil, nil, helpMessage, err
	}
	// if name is not set, generate a random one
	if pc.GetBaseConfig().Name == "" {
		id, err := util.RandIDWithLen(8)
		if err != nil {
			return nil, nil, helpMessage, fmt.Errorf("generate random id error: %v", err)
		}
		pc.GetBaseConfig().Name = fmt.Sprintf("sshtunnel-%s-%s", proxyType, id)
	}
	return &clientCfg, pc, helpMessage, nil
}

func (s *TunnelServer) handleNewChannel(channel ssh.NewChannel, extraPayloadCh chan string) {
	ch, reqs, err := channel.Accept()
	if err != nil {
		return
	}
	s.firstChannelMu.Lock()
	if s.firstChannel == nil {
		s.firstChannel = ch
	}
	s.firstChannelMu.Unlock()
	go s.keepAlive(ch)

View on GitHub (pinned to 6c8a8d0a97)

Solutions

1. Sidestep entirely by passing an explicit name: add --name my-tunnel to the ssh command.
2. If it recurs, check the host entropy: cat /proc/sys/kernel/random/entropy_avail and confirm /dev/urandom is readable inside the container.
3. Relax overly strict seccomp/sandbox profiles to allow the getrandom syscall.

Example fix

# before
ssh v0@frps "tcp 127.0.0.1:22 --remotePort 6000"

# after
ssh v0@frps "tcp 127.0.0.1:22 --remotePort 6000 --name my-ssh-tunnel"

# sidestep randomness entirely: always name your tunnels
ssh v0@frps "tcp 127.0.0.1:22 --remotePort 6000 --name prod-tunnel"

When it happens

Trigger: crypto/rand read errors: exhausted entropy at early boot on embedded/minimal VMs, a broken /dev/urandom in a badly built container, or file-descriptor exhaustion preventing the open. Requires the client to also have omitted the proxy name.

Common situations: Freshly booted minimal VMs or containers that block /dev/random; seccomp profiles in hardened containers denying getrandom(2); virtually never on normal Linux/macOS hosts.

Related errors

• generate crypto random: %w
• ps.Err
• internal error
• unknown public key for remoteAddr %q
• parse flags from ssh client error: %v

AI-assisted analysis of fatedier/frp@6c8a8d0a97 (2026-08-15). Data as JSON: /api/errors/64f3e0c5ef255b0d. Report an issue: GitHub.