4

I've managed to mess up some shared libraries on my system, and now my shell cannot be run, thus locking me out of the system. Both ssh, sftp, and scp, as configured on the remote system, seem to rely on the shell, so those alternatives are out. Really, it is not a big issue because I have some remote hands that can change my shell to sh via console.

However I'm curious, getting down to the mechanics of the SSH protocol, whether it is possible to authenticate and perform some manipulations on the remote system (eg, modifying /etc/passwd), without ever invoking the shell?

EDIT

Just to be fair, to the fellow who suggested specifying the alternative command/shell after the ssh command string (eg, ssh myhost /bin/sh): the man page does state:

If command is specified, it is executed on the remote host instead of a login shell.

which could definitely be confusing.

A__A__0
  • 393
  • 2
  • 6
  • 16
  • Change your login shell. If you normally use `bash` see whether you can edit `passwd` and use `sh` or `tsh` (or whatever) based on what you have installed. – ericx Aug 12 '14 at 17:01
  • @ericx, unfortunately that would require network access to the remote system, which I do not have due to the issue. Though, in fact someone on the remote end can change the shell via console – A__A__0 Aug 12 '14 at 17:04
  • 1
    @ericx - Never recommend that people edit /etc/passwd directly. Instead, we should always use `vipw` or for this instance, `chsh`. – EEAA Aug 12 '14 at 18:17
  • @chsh Please.. You can't, in fact, do it successfully. It's merely a metaphor for everyone in the room. Someone might be using LDAP, or someone might be using Kerberos or any of a myriad of other PAM options. The comment char length is somewhat limited. – ericx Aug 12 '14 at 18:23
  • 1
    @EEAA I didn't know about vipw. Never came up, but it's a good thing to have in my back pocket. Thank you, sir. – Parthian Shot Aug 12 '14 at 18:37

1 Answers1

3

[for the record only -- at the time of writing, the problem has long been fixed, hopefully]

With openssh, ANY command executed by sshd is executed via your login shell with the -c option:

  • command passed in the ssh command line (i.e. ssh user@host command)
  • command set up in the .authorized_keys file (i.e. command="..." ssh-rsa AAAA...)
  • command specified by the ForceCommand option in sshd_config
  • the execution of the ~/.ssh/rc script (via /bin/sh ~/.ssh/rc)
  • even the scp commands local to a server executed in response to a remote scp

So, if your login shell is faked (/bin/false or nologin) or broken, there is no way for you to execute anything remotely with ssh. That's also why no alternative shell is possible.

xhienne
  • 168
  • 6
  • `sftp` doesn't seem to work either in such a situation. If my first line of .bashrc is `echo SOMETHING`, then when trying `sftp localhost`, I get `Received message too long 168435779` as an error, and sftp exits. – Totor Nov 21 '19 at 13:49
  • You are right. I don't remember what I had in mind when I wrote that sftp might be useful, since it contradicts what I wrote just above. I guess I meant some sftp-only account (`ForceCommand internal-sftp` in the account configuration). Removing that sentence since it's confusing. – xhienne Nov 24 '19 at 20:11