Hi, We have a CLI that certain users get dropped into when they log in. One of the things they can go is generate certificates (actually .p12 key/certificate bundles) that they will then scp out of the box from another host. Problem is that if their default shell isn't sh, ash, dash, bash, zsh, etc. then things break. Is there a workaround to allow scp/sftp to continue to work even for non-shell accounts? Thanks, -Philip
On Fri, 8 Dec 2023 at 07:39, Philip Prindeville <philipp_subx at redfish-solutions.com> wrote: [...]> Problem is that if their default shell isn't sh, ash, dash, bash, zsh, etc. then things break. > Is there a workaround to allow scp/sftp to continue to work even for non-shell accounts?sftp should work regardless of the user's shell since it is invoked as a ssh subsystem which is independent of the shell channel. scp is built around the assumption that the shell is involved. It is possible for a restricted shell to allow scp and the arguments that it needs (there have been tools such as scponly and rssh) although it is very difficult to do this securely (rssh at least gave up trying entirely). I'd suggest not trying to support scp at all and concentrating on sftp. -- Darren Tucker (dtucker at dtucker.net) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
On 07.12.23 21:36, Philip Prindeville wrote:> Problem is that if their default shell isn't sh, ash, dash, bash, zsh, > etc. then things break. Is there a workaround to allow scp/sftp to > continue to work even for non-shell accounts?That sounds like the traditional "login is denied if the login shell is not listed in /etc/shells" mechanism is in effect, maybe because your sshd falls back to PAM? I take it that the users have something like /usr/local/sbin/OurMagicCLI set as their login shell? What happens when you add that to the list in /etc/shells ? Kind regards, -- Jochen Bern Systemingenieur Binect GmbH -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3449 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20231208/18bd5fb1/attachment.p7s>
On 07/12/23, Philip Prindeville (philipp_subx at redfish-solutions.com) wrote:> We have a CLI that certain users get dropped into when they log in. One of the things they can go is generate certificates (actually .p12 key/certificate bundles) that they will then scp out of the box from another host.Off topic, and assuming the .p12 bundles need to be post-processed by clients for use by ssh, might it not be worth considering an ssh certificate signing authority? I've made the proof-of-concept noted below, which adds certificates to forwarded agents. It doesn't need shell accounts, but prsently requires ssh public keys to be added to a yaml file: https://github.com/rorycl/sshagentca Cheers, Rory