Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
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)?
Here are just some of the things.
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.
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.
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.
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.
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.
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.
login program, and perhaps other services, but it rarely applies to sudo.
Mar 27, 2017 at 0:46
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.
