On an SSH connection, can you do everything that you can do on a console connection?

In other words, after launching a system and installing and configuring an SSH server on it, can you do all your further interaction with this system via SSH, and not use the console (except in cases that the SSH server is not available for some reason)?

  • There are a few things that require a console, but they are pretty low-level. Examples: fumbling with configuration when the network is down (possibly because of messed up configuration), fumbling with firmware settings (think SCSI controllers), some kinds of system upgrades, etc. Some people are fine with admining systems from another city; most people try to avoid it if possible. – Satō Katsura Mar 25 '17 at 12:19


Here are just some of the things.

superuser logon

On systems like FreeBSD and OpenBSD, the init program only permits logging on as user #0, in single user mode, on terminals marked as secure in the /etc/ttys file. And the login program (directly on OpenBSD, through a PAM module in FreeBSD) enforces the secure flag in multi-user mode.

Debian and Ubuntu similarly have the /etc/securetty mechanism. In all of them, the console, and the kernel virtual terminals (which are not necessarily the console, note), default to permitting superuser log on.

On OpenBSD, the out of the box default for SSH is not to permit log on as the superuser when using password or keyboard-interactive authentication (but to permit it when using public key authetication). The out of the box default for SSH on FreeBSD is to not permit log on as the superuser at all.

framebuffer output event/USB input programs

One can tunnel X over an SSH connection, and one can interact with programs that employ a terminal device. But programs that expect to perform I/O via Linux's "event" device system, via USB HID devices, and via a framebuffer device, are not operable via SSH.

further reading


One generally doesn't get sound tunnelled over SSH, either. One can manually direct programs that make sounds to a PulseAudio server over the LAN, or manually tunnel from the remote sound clients to a local PulseAudio server. But not all sound is PulseAudio, for starters.

further reading


Programs such as BRLTTY require direct access to the character+attribute cell array of a virtual terminal device. Where a server has BRLTTY set up, it cannot access SSH login sessions and display them in Braille, whereas it can display kernel virtual terminal login sessions.

further reading

emergency mode and rescue mode work

Bootstrapping into emergency mode or rescue mode does not start an SSH server. Neither mode starts all of the hooplah that underpins networking, let alone network services like an SSH server.

unpredictable PolicyKit stuff

PolicyKit has the notion of active and inactive login sessions. This tries to boil down what in the /etc/ttys system is a set of several attributes (on, secure, network, dialup) into a single true/false switch between "active" and "inactive". This doesn't quite fit the world where SSH and its ilk exist.

One can only have an "active" login session when one logs on on the console or on a kernel virtual terminal. Logging on via SSH is always considered to be an "inactive" login session. Surprising behavioural differences can result, because software authors and the system administrator can grant differing permissions to do stuff to active versus inactive login sessions.

further reading

  • While there is a lot of good information in this answer, it is somewhat misleading. The short answer is no: there is nothing which is intrinsically impossible to do over SSH, it's a matter of privileges which are a matter of configuration. The bit about root logins being restricted to the console is especially misleading as this only applies to the login program, and perhaps other services, but it rarely applies to sudo. – Gilles Mar 27 '17 at 0:46
  • What's misleading is erroneously conflating sudo with login. (-: – JdeBP Mar 27 '17 at 6:29
  • Whether using sudo is to be considered a “login” is a matter of ambiguous terminology. It gives access to an account, so it's a login into that account, even if it requires a previous login into another account. The point is that on most installations, you can get access to the root account from an SSH session, regardless of the fact that you can't log in to the root account using SSH alone as a privilege granting mechanism. What matters is whether you can run commands as root over SSH, and on almost every installation, it's true if you can run commands as root on a console. – Gilles Mar 27 '17 at 22:50

No, as long as you don't take the network connection down (or if you do, you reestablish it automatically enough, which is tricky). Commands don't intrinsically care through what interface they're issued.

However, it is possible that an SSH session would have fewer privileges than a console session. In this case, there may be things that are possible to do through an SSH session in principle, but are not authorized to a particular SSH session, or even to all the SSH sessions that can be opened in a particular configuration.

Logging in on the console obviously gives some privileges related to console interaction. Traditionally, this means having the right to interact with the terminal device (keyboard and display). Modern systems often tie other privileges to a console login, such as the privilege to mount removable devices, to access other peripherals such as audio devices, to initiate a suspend or reboot, etc. Modern Linux systems use polkit for this, with either ConsoleKit or systemd's logind to track which user has an active console session.

Traditionally, the superuser (root) has all privileges. All privileges does mean all, and it doesn't matter whether root is logged in through SSH or on a console. It is common to disable direct root logins over SSH, but that's up to the system configuration. Most Unix systems in their default configuration allow the root account to be reached via su or sudo from an SSH session, but it is possible to disable this, e.g. through pam_securetty.

Modern Unix systems can restrict the root account, for example with SELinux. A hardened system may allow root sessions over SSH, but restrict them in ways that don't apply to console logins. Again, this would be a matter of configuration, e.g. the SELinux policy.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.