Raspberry Pi Zero WH OTG Keyboard Passthrough over SSH Window!

[R0cket]

Hi,

I want to achieve what @thetekmerc does in this project:

https://github.com/macpczone/keyboard-passthrough

With the Raspberry PI Zero directly passing through keyboard input from the SSH Window logged into a Raspberry PI zero and make the Pi zero passthrough the keyboard input to the PC it is connect to via USB.

I connect to the Pi zero over IFI, log into it via SSH and want the Pi zero to passthrough the keys to the pc the PI Zero is connected to via USB cable.


I followed this guide to enable OTG Mode and let the PI zero act as a HID Keyboard:

http://www.isticktoit.net/?p=1383

the related Github Repositiory is:

https://github.com/girst/hardpass-sendHID


This all works fine and what i enter via:

echo -n "hello world!" | sudo ./scan /dev/hidg0 1 2

Is transfered to the PC connected to the raspberry PI.

But I want the keypresses including direction keys directly transferred to the pc, like in this porject: https://github.com/macpczone/keyboard-passthrough

For a video showing the the system in use, you can go to: https://www.youtube.com/watch?v=T3_Bwmw8XRw

Which unfortunately is for arduino and also requires the execution of a python script on a controlling pc.

I want what keys I enter into the ssh window to be passed through to the PC the Rapsberry Zero is connect to via USB over OTG.


Unfortunately I lack the skill to achieve this myself.

Anyone can help me with this or point to a project that has this functionality already included the way I need it?

Any help would be nice.

[topguy]

First you need to know that "characters" and "keyboard-events" are two different things. You can hold in "shift" and SSH will not send anything until you press another key. When you then press "a" key and shift is still held down, ssh will send an "A" to the other side.

When you want to get an "A" as a keyboard you still have to send an event for holding down shift and then an event for the "a" key.
And when it comes to special keys like arrow keys you probably have to take "terminal type" into account. ( http://www.termsys.demon.co.uk/vtansi.htm )

So my guess is that you still would need a program/script that will translate characters to key-events.

[R0cket]

Wouldn't it be possible to run such a translation tool also on the same raspberry zero?

I also found this project:

https://github.com/stjeong/rasp_vusb

It also has a translation application.

But the advantage here is that it does not require python.

If we now also could run the client application on the raspberry pi, then the goal would have been achieved.

Then all one would require is a ssh client and everything else would be running on the raspberry zero.

[thagrol]

Sounds like what you need is a script running on the zero to receive the terminal codes sent over the ssh connection, translate them into the correct key events.

I'm curious as to your purpose for this. I can see no use for it that isn't malicious. There's no back channel to the remote client that can display the PC's response. If you're sat at the PC why do things this way? If you're accessing the PC's display remotely just use VNC or similar for input as well as display.

I suspect what you want isn't going to be trivial.

1. You need to know what terminal type is in use at the remote end.
2. You need to know what locale is being used at the remote end
3. You need to identify as the correct keyboard locale to the PC
4. You have to translate from terminal code to an intermediate code such as unicode or utf-8
5. You have to translate that intermediate code from the locale of the client to that of an en-US keyboard as the HID keyboard spec mandates that all key events are sent as if by such a keyboard and translated to the correct locale by the USB host.
6. You then have to generate and send the correct key events.
7. Then there's events coming the other way: keyboard LED control, setting capslock and numlock state, various control codes that affect the remote device.

This could all be done on one Pi zero none of it is computationally expensive. Translation in most casses will be a case of using the correct lookup table.

[R0cket]

My ultimate goal is BIOS level remote access. VNC does not allow BIOS Level Remote.

How I get video, I have figured out, but I need to issues keyboard commands to the remote machine at BIOS level.

I just need it for about 4-5 pc's, so it does not need to be generic.

This shouldn't be too difficult too achieve.

[thagrol]

My ultimate goal is BIOS level remote access. VNC does not allow BIOS Level Remote.

I stand corrected There is a ligitimate use for this tech.

How I get video, I have figured out, but I need to issues keyboard commands to the remote machine at BIOS level.

I just need it for about 4-5 pc's, so it does not need to be generic.

Fair enough

Decide on the terminal type you'll always be using from the remote end and create a single lookup table to translate those codes into the apropriate key events.

This shouldn't be too difficult too achieve.

Probably not, with the restricted circumstances you're talking about. There are other issues you need to consider though:

1. Physical security. Anyone with physical access to the zero can steal it or pull the SD card and modify its contents.
2. Powering the zeros
   
   Powering them from the host PC's USB port probably won't work. You might get away with this if the USB ports on the PC remain powered across a shutdown and reboot but many don't. That means boot when the PC does and an improper shutdwon when it cuts power.
   
   Powering them seperately would work with the proviso that you should modify the USB cable between the zero and the host so that the zero doesn't backfeed power to the host.
3. Boot times. Using a stock raspbian boot time is going to be over a minute. You can get that down to a few seconds with something like a tailored buildroot OS but it still might not be quick enough to hit the sweet spot when you can enter the BIOS. Plus you have to allow time to make the remote connection.
4. Remote control of power on/off. If the only way into the BIOS is by "Press F2" at the right moment during boot it defeats the object of the project if you need someone there to power cycle the PC. Yeah, I know you can trigger a reboot from a running OS but that doesn't cover all cases.
5. SD card corruption. Without a clean shutdown before power is removed every time you'll corrupt the SD card. Using a read only file system or running everything entirely from RAM can minimise the risk.

If it were me, I'd mount the zero inside the PC's case, tap the PC's 5v standby for power, connect some GPIO in parallel with the power button, and use a buildroot based run entirely from RAM custom OS build. For a project I did a while back that involved a zero mounted inside a PC and connected to its buttons see here: https://github.com/thagrol/fakewake

[BeauSlim]

This sounds somewhat similar to https://github.com/Fmstrat/diy-ipmi

[R0cket]

Thanks for the feedback and points of concern.

I have figured out most of it.

1. The Pi's will be in my home connected to my wifi.
2. They will be powered by the PC's USB.
3. I will cut and enable power of the whole pc (that's genius right!)via Tasmota devices: https://github.com/arendst/Tasmota
4. I will setup the pc to power the USB also in power off state, so the zero is on when I start to boot.
5. I will make the sd write protect once everything is setup.

I'm coming from https://github.com/Fmstrat/diy-ipmi

Actually I like this project even better: https://github.com/pikvm

This is quite an advanced project.

But I have some issues with them. I just need a simple Keyboard issue solution over wifi.

But I just need a small part of it. It looked too difficult to just pull the OTG HDI part off the project and also that project uses Serial connection between PI and Zero.

I want direct ssh connection cutting off the Master PI.

Basically what I want is a replacement for my vPro Intel KVM machines. I don't want to be limited to Q-Chipsets and Intel CPU's. So there is a legitimate need for it. Not everybody who gets a pi zero wants to see the world burn

BTW: I have achieved what fakewake does a bit easier. My goal was to have a reliable wireless WOL. I just connected my Raspberry via 5v or own PSU and via LAN cable to the wirlesss pc's LAN, and issued WOL from the Raspberry to the PC. You need to assign static IPS on the LAN interfaces to have a direct connection. An voila, you have Wake on WLAN. You can even go easier and also solve the hard reset issues also via a tasmota device. I had vPro system, so I could hardreset via Intel AMT. Thats why I have switched to use tasmota for the waking purposes. vPro or not, with tasmota I can start and hardreset via Wifi! Matter of fact I have 4 more tasmota devices delivered today, as they are so much fun to work with.

[thagrol]

BTW: I have achieved what fakewake does a bit easier. My goal was to have a reliable wireless WOL. I just connected my Raspberry via 5v or own PSU and via LAN cable to the wirlesss pc's LAN, and issued WOL from the Raspberry to the PC. You need to assign static IPS on the LAN interfaces to have a direct connection. An voila, you have Wake on WLAN. You can even go easier and also solve the hard reset issues also via a tasmota device. I had vPro system, so I could hardreset via Intel AMT. Thats why I have switched to use tasmota for the waking purposes. vPro or not, with tasmota I can start and hardreset via Wifi! Matter of fact I have 4 more tasmota devices delivered today, as they are so much fun to work with.

Fair enough. The main reason for creating fakewake was that I couldn't get WoL to work reliably on several PCs. Secondary reasons were that remote shutdown and reset required software runing on the PC or logging in to the PC (or both).

Those devices look interesting but why use multiple devices when one can do it all?

You shouldn't need to set any IP addresses on the PC's ethernet interfaces for WoL to work. WoL works below the TCP/IP level in the network stack. You do need them if the tasmota and PC need to communicate over ethernet or the OS on the PC needs them to enable WoL.

Incidentally, there's another project on my github that does part of what you want. Takes a text string and passes it to a USB host as HID keyboard events. You can find it here: https://github.com/thagrol/pwdgen