How to connect ssh and /dev/nmdm devices

[Willem Jan Withagen]

On 2015-01-20 18:48, Paul Vixie wrote:
>
>
>> Willem Jan Withagen <mailto:wjw at digiware.nl>
>> Tuesday, January 20, 2015 8:37 AM
>>
>>
>>
>> What is the easiest way to "propagate"  the full-duplex tty stream
>> from a SSH-login to a /dev/nmdmXXXXA.
>
> somewhat expectedly, i use <http://www.freshports.org/sysutils/rtty/>
> for this. with a restricted shell, i can offer console access to guests
> via ssh. "cu" also works, but lacks rtty's background logging.

HI,

I got several suggestions, and in the end I went for this one.

Why?
The code base is small and simple it does exactly what I required, no 
more, no less.

Getting it to work requires a bit of careful configuration but one 
you've done that you end up with SSH users which can do multiple logins 
and all see the same console. Input and things all the same. So no 
exclusion because you've left your terminal open at work and went home.
Nifty stuff.

Basic install:

1)
pkg install rtty.

This populates the /usr/local/rtty tree. And that is where just almost 
everything happens.

2)
In /usr/local/rtty/dev create links to the nmdm-devices you'd like to 
connect to the console:
root at bhyve00:/usr/local/rtty # ls -l dev
total 1
lrwxr-xr-x  1 root  wheel  14 Jan 22 11:13 bh1101A -> /dev/nmdm1101B

3)
Create a "shell" to connect to this console:
root at bhyve00:/usr/local/rtty # cat bin/rtty-shell
#!/bin/sh

exec /usr/local/rtty/bin/console "$LOGNAME"

# exec /usr/bin/cu -t -l /dev/nmdm1101A
# exec /usr/bin/tip vm1101
exit

And make it executable:
root at bhyve00:/usr/local/rtty # ls -l bin/rtty-shell
-rwxr-xr-x  1 root  wheel  127 Jan 22 11:15 bin/rtty-shell

As you can see you can use other commands as well, but both tip and cu 
are all about exclusive access.

Trick here is that LOGNAME is what the user is using for login, and that 
is also the name of the device in ../dev to which he/she is connected.

4)
Create the user in /etc/passwd:
root at bhyve00:/usr/local/rtty # grep bh1101A /etc/passwd
bh1101A:*:10001:10001:Bhyve dome remote access 
user:/home/bhyvedemo:/usr/local/rtty/bin/rtty-shell

And put him in /etc/group to make things complete:
root at bhyve00:/usr/local/rtty # grep bh1101A /etc/group
bh1101A:*:10001:

Group is needed for the rights on the socket-device in step 6.

5)
Which also requires an entry in /etc/shells to work:
root at bhyve00:/usr/local/rtty # grep rtty /etc/shells
/usr/local/rtty/bin/rtty-shell


6)
Having done all this the we need to make sure that the accessrights on 
the linked device are set correctly:
root at bhyve00:/usr/local/rtty # cat owner/bh1101A.sock
root:bh1101A

This will prevent another user from hijacking a console which is not 
his, in case of access by other means.

7)
Last ting to do is to start the server deamon that does the 
multiplexing/sharing stuff:
/usr/sbin/daemon -cf /usr/local/rtty/bin/Startup

Which you could dump into /etc/rc.local, or the more brave would write a 
rc.d compliant startup script.

8)
Test:
root at bhyve00:/usr/local/rtty # ssh bh1101A at localhost
Password for bh1101A at bhyve00:
Last login: Wed Jan 21 12:42:37 2015 from mail.ip6.digiware.nl
FreeBSD 11.0-CURRENT (GENERIC) #19 r277452: Wed Jan 21 08:01:54 UTC 2015

Welcome to FreeBSD!

connected
(use (CR)~? for minimal help; also (CR)~q? and (CR)~s?)
[authorized]
[bh1101A@/dev/pts/4 connected]


FreeBSD/amd64 (FreeBSD-11) (ttyu0)

login:
========================

Even if the VM is not yet running you can connect to the server, and 
then start the VM, to all of its booting output. Or interact with the 
loader. It also works to actually install a VM from CD.

Not that on 10.0 installs the default console is OFF, en needs to be 
edited in /etc/ttys to
	ttyu0   "/usr/libexec/getty std.9600"   vt100 on secure
or
	ttyu0   "/usr/libexec/getty std.9600"   vt100 onifconsole secure
For more recent relesase where init(1) understand onifconsole

Probably there are some more things to do, like getting rtty and ssh to 
be silent on login, etc....
But these are the essentials.

Rinse and repeat steps 2, 4 and 6 to create a new access.
After which you net to restart the server to get it to learn a new device.

And even though I'm a CLI junky ....
Next step would to see if we can use all kinds of java(script) sshlibs 
to connect, so you can embed this in a management webconsole.

Enjoy,
--WjW