This is by design.
Due to (what I think is) some sort of bug on the Linux version (Kali v2.0) of my remote computer, my TTY text consoles do not start until I locally sit on the machine and press CtrlAltFn.
This is not a bug. This is systemd Linux working as designed. TTY login services for kernel virtual terminals are started on demand by
logind, as they are switched into the foreground. If you are accessing the the machine remotely and using ConSpy, you are of course not switching kernel virtual terminals into the foreground.
agetty command the proper method to spawn a TTY text virtual console?
Yes, and no. Yes, it's the way to spawn a getty/login service. No, it doesn't spawn the virtual terminal itself. No, you don't run it directly.
logind does this. There's a systemd service, named
autovt@ttyN.service, for each virtual terminal. That is what runs
agetty. One starts that service manually, or lets
logind start it upon demand.
The problems of
tmux with systemd.
Of course, as noted you are using the kernel's virtual terminal subsystem and ConSpy as the server and client parts of a system like
tmux. You could switch to using
The problem with
tmux is that they don't interoperate well with systemd. This is a known systemd problem, and is also by design. If you start the server part of
tmux from within a login session that is managed directly as a service by systemd (as
autovt@ttyN.service services are, and as indeed
firstname.lastname@example.org services are when running SSH in
Accept=yes mode) then systemd kills the server when you log out, because by design it kills all still-left-around processes within a service when that service terminates, and logging out of such login session services counts as termination.
The world has a choice of workarounds for this design conflict, include such things as changing the kill mode of
sshd@.service. By far the best approach is to make the
tmux server itself into a managed service. You thus don't start
tmux by logging in and running it interactively. You start it by having it as a fully-fledged service that is started and stopped via systemd.
At which point, all of the stuff in
tmux to fork off a server process in the background is at best overengineered, as the background server part is all that a systemd-managed
tmux service needs to do, and it doesn't need to "dæmonize" its server. (Ironically, the problem that
tmux have with systemd is yet another example of why it is actually impossible to safely, securely, and reliably "dæmonize" from an interactive login session.)
Since you mention alternatives, here is another: nosh has a user-space virtual terminal system. You could run the nosh service manager under systemd, and some of the nosh
terminal-emulator@vcNservices under it, talking to the emulated terminals from SSH login sessions with
console-ncurses-realizer. (If you adjusted ConSpy to not hardwire device names as it currently does, you could even view the emulated terminals with ConSpy, since there's a vcsa-compatible display buffer available.)
console-terminal-emulator doesn't "dæmonize" and does just the one job, of emulating a terminal and sitting between the master side of a pseudo-terminal and the emulated display and input.
There are a couple of incidental benefits of this: It's not constrained by kernel-space design constraints, and so is a more complete DEC VT emulation than the emulator programs built into kernels. Terminals can be resized with the ordinary DEC control sequences, to arbitrary sizes. Terminals auto-reset, for security, immediately on log-off rather than on next invocation of log-on.