So it seems. I find the man-page slightly misleading in that regard. Other interesting way to escape /bin/false login shell from ssh man page:
~/.ssh/rc
Commands in this file are executed by ssh when the user logs in,
just before the user's shell (or command) is started. See the
sshd(8) manual page for more information.
If you copy shellcode to that file with scp (which I'd imagine would not try to invoke login shell), you'd get shell to the server.
I just tested it and i didn't get it to work. ~/.ssh/rc is not executed directly but given as an parameter to your shell (/bin/false) which will ignore the parameter.
To be more precise sh -c /bin/false -c '/bin/sh .ssh/rc' is executed where /bin/false is your shell as ssh uses popen(3) to run the command /bin/false -c '/bin/sh .ssh/rc'. I tested several shells which may be used as sh and none seems to read a user configurable file.
If you use a static linked shell and enabled PermitUserEnvironment an attacker can still use LD_* variables to circumvent restrictions as /bin/sh is typically dynamically linked.
I don't think it would work directly through scp. From what I can tell from skimming the source, it is really just a wrapper over ssh. Meaning: it forks an ssh, with the commands 'scp -t/-f' on the distant side, and does its magic to connect the pipes where they should go. 'scp -v' gives the exact command, but I don't think it works without previously having a shell.
But, if you have access to the filesystem through other means, you could use the .ssh/rc trick to bypass /bin/false, and get ssh access.
