On: Unix shells are generally not viable access contro...

[blueflow]

The post does not back up its headline? How can a SHELL=/bin/false be bypassed via SSH?

For the various kind of forwarding SSH supports, they all can be disabled via sshd_config.

[tyingq → blueflow]

I think it's comparing to the "old days" when there was a more 1:1 relationship of service-on-a-port plus a specific userid. Because the article specifically calls out:

"One of these services is SSH itself, since you can generally initiate SSH sessions and ask for port forwarding or other features that don't cause SSH to run the login shell"

But, even that sort of falls apart because we also had inetd in the "old days", which spawned lots of different things as different users without invoking a login shell.

Generally, the article seems to be lamenting that not everything is gated by userids and groups anymore. That's true, but it doesn't seem recent to me. Aside from inetd, I could (and did) massage kermit (or uucp, etc) into being a multi-service gateway in the 1980's.

I suppose it's somewhat correct in the idea that figuring how any particular service limits rights is now very complicated. You have the old familiar stuff (users, groups). But now you also have virtual machines, containers, namespaces, capabilities. And things like seccomp and apparmor. Then, various sandboxing schemes within utilities, languages and frameworks or OS facilities like ebpf.

[juped → blueflow]

It seems to me (it's kinda unclear) that the article is talking mostly about various other things pulling users from /etc/passwd and the ssh thing is an aside. For anon ssh you can have e.g.

  Match User anonymous
          PasswordAuthentication yes
          PermitEmptyPasswords yes
          DisableForwarding yes
          PermitTTY no

and possibly ForceCommand and ChrootDirectory depending on how you're sandboxing anonymous and to what; plus a restricted login shell (the above anonymous user of mine has gotsh, got's version of git-shell).

[batch12 → blueflow]

Ive used something like ''' ssh -t user@host /bin/sh '''

To bypass shell restrictions in the past, but I'm not sure if that will work with your example.

[blueflow → batch12]

This won't work because the command send to the server is not an argument vector, but a command string interpreted by the users login shell.

`ssh -t user@remote /bin/sh asdf` would execute `/bin/false -c "/bin/sh asdf"` on the remote.

[batch12 → blueflow]

Makes sense, thanks for the clarification.

[LinuxBender → batch12]

Feel free to try it out

    sftp share@ohblog.net   (no pw)

    # grep share /etc/passwd /etc/shadow
    /etc/passwd:share:x:5002:5000::/data/sftp/share:/bin/false
    /etc/shadow:share::19614::::::

The partially redacted /etc/ssh/sshd_config is copied to /pub/ in the SFTP account.

If you can bypass the restriction please do share how it was done. I don't offer bug bounties but I think people would find it interesting. OS is Alpine Linux. All CPU mitigations are disabled in the VM. No MAC As in no SElinux or AppArmor. I won't complain, just pretty please don't DDoS the server or anything that would make that VPS do work.

Feel free to also tinker with the web and voice chat server on that node.

[salzig → blueflow]

For a port-forward with `-N` on client side.

Besides that, I don’t know.

[emmelaich → blueflow]

You can pass various env vars with ssh, typically restricted to LANG and LC_*.

But I vaguely remember that in the past it may have been anything, including SHELL.