SSH Serial Console

Latest response

Once connected to a serial console via ssh, how do you disconnect from the session. I've been unable to find anything on disconnecting. I've tried using ctrl+ an nothing seems to work. I thought maybe ctrl+] or ctrl+~ but nothing. Right now the only way I can log out of the serial session is to kill the terminal window or search for the connection using lsof and killing the PID.


Your question is a bit unclear/lacking in details. Serial devices aren't generally SSH'able - at least not directly - so your disconnect is likely to depend on what's being used to create your IP-to-serial gateway.

Similarly, your termination key-sequence is likely to depend on what SSH client you're using. Absent modifications, aborting an SSH session (if going from a UNIX/Linux shell rather than from a PC tool like PuTTY) is a matter of typing ~..

Apologies, yes my description is lacking. I'm using RHEV and have setup one of the VMs to allow virtual console connections by adding "console=ttyS0" to the "GRUB_CMDLINE_LINUX" line in 'sysconfig/grub'. Now I'm able to use the following command to connect to the text console via ssh => ssh -i .ssh/serialconsolekey -t -p 2222 ovirt-vmconsole@. Once connected, I am able to login and see console messages during a reboot. Your "~." suggestion does work, but it also kills the entire ssh session. This is what I mean by the 'entire session': first, I login to one of our admin Linux servers and start a screen session. Then I use one of the virtual terminals screen creates to execute the above ssh command. Once I use "~." to disconnect, it disconnects my ssh session to the Linux admin server. Once I reconnect and reattach to the screen session I see I am still logged into the text console of the VM.

If there's not a better way to disconnect the text console session I can live with using "~." -- I'll just use our admin box minus the screen session, as that does work, even though it also kills the connection to the admin box.

Ok, that makes a bit more sense. Technically, you're not SSHing to the VM's console - you're SSHing to the VM-host and it's gatewaying for you.

In this scenario, there's actually two connections to account for: the ssh to the VM-host and the VM-host's connection to the VM's virtual console. The ~. method only addresses the connection to the VM-host.

The VM-host's connection to the VM's virtual console is kind of an "always on" proposition. This isn't inherently problematic, but it does mean that someone carelessly leaving root logged in the VM's console gives anyone that has permission to the VM-host's console-gateway service the ability to assume whatever rights are active on the console. You can mitigate this, to a degree, by setting idle-timeouts on the login session.

There's a few ways to achieve this.

  • The easiest way is probably to set the TMOUT-environmental in /etc/profile. That said, if someone execs another shell, this environment-setting may have no meaning in the substituted shell and the idle timeout may not take place.
  • Similarly, you should be able to get the getty service to time-out idle connections for you - probably something on the order of setting LOGIN_TIMEOUT in the /etc/login.defs. In either case, if someone drops the console connection without having logged out, the idle session will auto-terminate after the set period of time.
  • There's likely also some PAM mods you can make (I just don't recall them off the top of my head)

Either idle-timeout method should reduce the likelihood of someone SSHing through to the virtual console and finding themselves with a #-prompt waiting for them.

Thank you for the information. I'll look at updates to the login.defs -- that seems more suited to our needs.