#6 ConSpy not working when running remote network connection from rc.local

[Sopalajo de Arrierez y Torrezno]

I don't know if this is a conspy-related problem, but if not, I hope it could at least be referred to in any FAQ.

If I configure "/etc/rc.local" on my Linux machine to remotely connect to some type of PPP network, ConSpy can not visualize my TTYs. It just shows an empty screen on any terminal. I can write, and my typings are shown, but no remote orders seem to be given.

This is my /etc/rc.local:

#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

# Iniciando demonio SSH:
/etc/init.d/ssh start

# Iniciando conexion VPN a red Themiscyra (PPTP):
pon ThemiscyraVPN persist holdoff 60 maxfail 0

# Iniciando conexion VPN a red Utopia (OpenVPN):
openvpn /etc/openvpn/Utopia.ovpn

# Iniciando conexion VPN a red Trantor (PeerVPN):
peervpn /etc/peervpn/peervpn.conf

exit 0

I can repair the problem if I do:

luis@kali:~$ sudo ps -e | grep "ppp" -i
 1016 ?        00:00:00 pppd
luis@kali:~$ sudo poff

luis@kali:~$ sudo ps -e | grep "openvpn" -i
 1017 ?        00:00:00 openvpn
luis@kali:~$ sudo kill 1017

luis@kali:~$ sudo ps -e | grep "peer" -i
 2425 ?        00:00:00 peervpn
luis@kali:~$ sudo kill 2425

Tested with (just one of these packages is enough to generate the problem):

PPTP connections (pptp-linux package).
OpenVPN connections (openvpn package).
PeerVPN connections (compiled package from the programmer at http://www.peervpn.net/ ).

Maybe the problem lies in using "/etc/rc.local" for this.

Just ask more data or images if you need them.

[Sopalajo de Arrierez y Torrezno]

ConSpy not working when running remote network connection from rc.local

Extra data: when locally going to the computer, all the TTYs show:

A start job is running for /etc/rc.local

Maybe this is not a ConSpy problem.

[Sopalajo de Arrierez y Torrezno]

Well, after several tests, I think that maybe the rc.local file is not the problem here.
This is my way to reproduce the problem:

1.- Start Kali Linux v2.0 live DVD (tested with 32 bits version). The system boots directly to GUI.
2.- Start SSH.
3.- Remotely log via SSH.
4.- Install ConSpy from the repos.
5.- All the TTYs except number 1 show a blank screen with the cursor blinking. You can type, but nothing happens.

Tested too with installed onto hard disk version.
Tested too with latest v1.13 2015-09-21.
Tested on Desktop PC and RaspBerry Pi 2 Kali 2.0 versions.

[Sopalajo de Arrierez y Torrezno]

Some more info:
* Kali v1.1.0 running ConSpy v1.8 seems to work without this flaw.

[Sopalajo de Arrierez y Torrezno]

New data: it seems that ConSpy generates OK the TTYn if I first phisically go to the machine and press Ctrl+Alt+Fn (Ctrl+Alt+F2, then I can remotely access to conspy 2... etc).

It seems that Kali 2.0 is based on Debian jessie, which has switched to systemd for spawning consoles.

[Russell Stuart]

It seems that Kali 2.0 is based on Debian jessie, which has switched to systemd for spawning consoles.

Nah. Debian stable (ie Jessie), is what I run on my laptop every day. Ergo, it is what I test conspy on, and it works.

Unfortunatly I am absolutely certain Jessie has not switched to using systemd for driving consoles, because if it did I would be both amazed and happy. Amazed because I doubt the kernel API's conspy relies on would be supported by systemd, and happy becuase I would not have to do any work to fix it.

I am not familiar with Kali, so I looked it up. Both Kali current and Kali next (I don't know which Kali 2.0 refers to) both use systemd version 215. Systemd did indeed add a module to take over virtual consoles - but that happened in verison 217. (See: http://www.phoronix.com/scan.php?page=news_item&px=MTgwNzQ ) So that isn't what is happening here.

I can only guess at what is happening at this point. Did you enable a login on the virtual consoles (tty0 .. tty6)? Maybe Kali 2.0 doesn't do it by default whereas maybe v1.1.0 did.

[Sopalajo de Arrierez y Torrezno]

I don't know what is "enabling a login on the virtual consoles". How can I check it?
I think I have not changed the default behavior for Kali about the TTY management.

[Russell Stuart]

How can I check it?

On my Debian Jessie laptop the getty's (getty is the name of the program that does the login prompt on terminals) for the virtual consoles are controlled by symlinks in the /etc/systemd/system/getty.target.wants directory.

$ ls -l /etc/systemd/system/getty.target.wants
lrwxrwxrwx 1 root root 34 May  7 16:55 getty@tty1.service -> /lib/systemd/system/getty@.service

That tells me there will be a login prompt on virtual console tty1, and indeed there is:

$ ps -ef | grep [g]etty
root      1118     1  0 08:01 tty1     00:00:00 /sbin/agetty --noclear tty1 linux

On Debian Jessie you enable / disable these getty's by creating / deleting those symlinks. Eg, to enable a login on virtual console tty2 I run this command:

$ sudo ln -s /lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty2.service

That will take effect on next boot. To start the getty immediately run this command:

$ sudo systemctl start getty@tty2.service

A ps shows it worked:

$ ps -ef | grep [g]etty
root      1118     1  0 08:01 tty1     00:00:00 /sbin/agetty --noclear tty1 linux
root      4594     1  0 11:17 tty2     00:00:00 /sbin/agetty --noclear tty2 linux