On 2015-01-20 18:48, Paul Vixie wrote:
Willem Jan Withagen <mailto:w...@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.
I got several suggestions, and in the end I went for this one.
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.
pkg install rtty.
This populates the /usr/local/rtty tree. And that is where just almost
In /usr/local/rtty/dev create links to the nmdm-devices you'd like to
connect to the console:
root@bhyve00:/usr/local/rtty # ls -l dev
lrwxr-xr-x 1 root wheel 14 Jan 22 11:13 bh1101A -> /dev/nmdm1101B
Create a "shell" to connect to this console:
root@bhyve00:/usr/local/rtty # cat bin/rtty-shell
exec /usr/local/rtty/bin/console "$LOGNAME"
# exec /usr/bin/cu -t -l /dev/nmdm1101A
# exec /usr/bin/tip vm1101
And make it executable:
root@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.
Create the user in /etc/passwd:
root@bhyve00:/usr/local/rtty # grep bh1101A /etc/passwd
bh1101A:*:10001:10001:Bhyve dome remote access
And put him in /etc/group to make things complete:
root@bhyve00:/usr/local/rtty # grep bh1101A /etc/group
Group is needed for the rights on the socket-device in step 6.
Which also requires an entry in /etc/shells to work:
root@bhyve00:/usr/local/rtty # grep rtty /etc/shells
Having done all this the we need to make sure that the accessrights on
the linked device are set correctly:
root@bhyve00:/usr/local/rtty # cat owner/bh1101A.sock
This will prevent another user from hijacking a console which is not
his, in case of access by other means.
Last ting to do is to start the server deamon that does the
/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.
root@bhyve00:/usr/local/rtty # ssh bh1101A@localhost
Password for bh1101A@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!
(use (CR)~? for minimal help; also (CR)~q? and (CR)~s?)
FreeBSD/amd64 (FreeBSD-11) (ttyu0)
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
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.
email@example.com mailing list
To unsubscribe, send any mail to