So I set up a fresh key to use for this test, and gave it similar parameters.
I wasn't aware of the "restrict" argument but the original authorized_keys entries had a long list of restrictions:
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="/.../receive.ksh" ssh-rsa ...
I did the same thing as I had done with the live key and got the same results (as expected).
It then occurred to me that the issue is probably on the server side, which did not change. So I set up the user and forced command on 3 lab servers:
OS OpenSSH version
Ubuntu 18.04 OpenSSH_7.6p1 Ubuntu-4ubuntu0.7, OpenSSL 1.0.2n 7 Dec 2017
Solaris 11 OpenSSH_8.4p1, OpenSSL 1.0.2zf 21 Jun 2022
HP-UX 11.31 OpenSSH_8.1p1+sftpfilecontrol-v1.3-hpn14v20, OpenSSL 1.1.1d 10 Sep 2019
I got the following results:
OS ssh sftp SSH_ORIGINAL_COMMAND
Ubuntu 18.04 Hung waiting for input, pressed ^C Obtained sftp prompt. Not logged
Solaris 11 Hung waiting for input, pressed ^C Hung waiting for input, pressed ^C Command: internal-sftp
HP-UX 11.31 Hung waiting for input, pressed ^C Hung waiting for input, pressed ^C Command: /opt/ssh/libexec/sftp-server
So the issue looks like it happens across Linux distributions, but not on non-Linux. Curiouser and curiouser.
I then changed the forced command to /usr/bin/logger and got similar results. I think the default priority for logs on our servers goes nowhere; next round I'll have to specify a priority that is actually logged.
Hope you have a great weekend, and thanks for your help so far.
--
Mike McManus
Principal – Technology Security
GTO Security Governance Team - Unix
P: He/Him/His
AT&T Services, Inc.
20205 North Creek Pkwy, Bothell, WA 98011
michael.mcmanus@xxxxxxx
-----Original Message-----
From: Jochen Bern <Jochen.Bern@xxxxxxxxx>
Sent: Friday, July 7, 2023 5:28 AM
To: openssh-unix-dev@xxxxxxxxxxx
Cc: MCMANUS, MICHAEL P <mm1072@xxxxxxx>
Subject: Re: RE: RE: Subsystem sftp invoked even though forced command created
On 06.07.23 23:37, MCMANUS, MICHAEL P wrote:> So changing the forced
command as stated will break the application. I
> would need to create a test bed to simulate the listener rather than
> use the server as is, where is. That may produce false or misleading
> results.
Since the forced command is tied to the specific keypair in the
authorized_keys, you could
-- test with a different keypair or
-- use an additional 'from="..."' option to split the entry between your
test client and the productive clients.
> Oddly enough, the same behavior occurs when the embedded key is used
> to launch an interactive sftp session from the host running the
> legitimate client:
>
> # sftp -i ${embeddedKey} ${user}@${host}
> <Standard warning from /etc/issue.net>
> Connected to ${host}.
> sftp> ls
> README collectors receive-data.ksh tmp
> sftp> ^D
> So we can probably write off any idiosyncrasies of WinSCP and work only
> with OpenSSH. Note there is no output from the script whatsoever.
In that case, let me repeat my quick test on one of our systems ... :
> [root ~]# cat /etc/centos-release
> CentOS Linux release 7.9.2009 (Core)
> [root ~]# rpm -q openssh
> openssh-7.4p1-22.el7_9.x86_64
> [root ~]# tail -1 ~autoquest/.ssh/authorized_keys | sed -e 's/AAA.*/.../'
> restrict,from="127.0.0.1",command="/bin/logger -t AutoHack" ssh-rsa ...
> [root ~]# ssh-keygen -l -f /home/autoquest/.ssh/authorized_keys | tail -1
> 4096 SHA256:NSG4SRm/sLQxX4Xc5lQiMc3Q9S5j0Vavp7gu+voAwhI CNG-000121900000-010098-01 (RSA)
> [root ~]# ssh-keygen -l -f /home/bongo/.ssh/*.pub
> 4096 SHA256:NSG4SRm/sLQxX4Xc5lQiMc3Q9S5j0Vavp7gu+voAwhI CNG-000121900000-010098-01 (RSA)
> [root ~]# su -l -s /bin/bash bongo
> [bongo ~]$ echo "foo bar baz" | sftp autoquest@127.0.0.1
[... confirm host keypair, output of /etc/issue.net ... then it just
hangs ...]
> ^CKilled by signal 15.
> [bongo ~]$ exit
> logout
> [root ~]# journalctl -t AutoHack
> -- Logs begin at Thu 2023-06-22 11:07:33 CEST, end at Fri 2023-07-07 14:20:35 CEST. --
> Jul 07 14:19:35 cng-000121900000-010098-01 AutoHack[15837]:
... no SFTP login, but also no stdin being logged ...
Kind regards,
--
Jochen Bern
Systemingenieur
Binect GmbH
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
