openssh unix dev - Jan 2017 - sshd custom shell script for specifc user

Hi Darren,  the clients config would need customer to change firewall
settings to allow 1023 port.

my server is behind the firewall. firewall settings say that my server 1023
is not accessable from outside. So If user tries -p 1023, it is rejected.
 hence user can only issue
ssh customuser at ip . I am trying to instead connect to 1023 from my server,
which doesnt go to firewall, hence from my server
ssh admin at 127.0.0.1 -p 1023 should work. I have shared sshd logs , can you
see if it gives hint on why reading passwd happens in sshd side and echo
and read for user happens at client side.



server logs with debug level=3
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1:  Deny port forwarding to host 127.0.0.0/8
debug1: sshd version OpenSSH_6.6, OpenSSL 1.0.1h 5 Jun 2014
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: inetd sockets after dupping: 3, 3
Connection from 10.220.82.17 port 54086 on 10.220.167.184 port 22
debug1: Client protocol version 2.0; client software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6
debug1: list_hostkey_types: ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
WARNING: /usr/local/etc/moduli does not exist, using fixed modulus
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user cliuser service ssh-connection method none
debug1: attempt 0 failures 0
debug1: user customuser matched 'User customuser' at line 35
Could not get shadow information for customuser
Accepted none for cliuser from 10.220.82.17 port 54086 ssh2
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max
16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_global_request: rtype no-more-sessions at openssh.com
want_reply 0
debug1: server_input_channel_req: channel 0 request pty-req reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: session_pty_req: session 0 alloc /dev/pts/3
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request shell reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
Starting session: forced-command (config) '. /etc/myscript' on pts/3 for
cliuser from 10.220.82.17 port 54086
secadmin at 127.0.0.1's password:




On Tue, Jan 31, 2017 at 10:53 AM, Darren Tucker <dtucker at zip.com.au>
wrote:
> On Tue, Jan 31, 2017 at 3:55 PM, Sudarshan Soma <sudarshan12s at
gmail.com>
> wrote:
> > Thanks  Darren, the intention to do this :
> > allow users to access my own shell/CLI(including authentication) on
port
> 22.
> > their firewall settings doesnt allow anything other than port 22, so I
> would
> > internally redirect to port 1023 when customuser is provided.
>
> If the clients are openssh you could use it in "stdio forwarding"
mode
> to establish an end-to-end connection to the sshd on port 1023.
>
> You'd configure the server something like this in the main sshd's
config:
>
> Match user customuser
>   MaxSessions 0
>   PermitOpen localhost:1023
>
> then in the client's config
>
> Host yourapplication
>   ProxyCommand ssh -W localhost:1023 customuser at yourgateway
>
> which should allow "ssh admin at yourapplication" to work.
>
> --
> Darren Tucker (dtucker at zip.com.au)
> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
>     Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
>

On Wed, Feb 1, 2017 at 6:05 AM, Sudarshan Soma <sudarshan12s at gmail.com>
wrote:
> Hi Darren,  the clients config would need customer to change firewall
> settings to allow 1023 port.
Not in the configuration I proposed: the first ssh command runs the
second to connect to the server so you'd end up with TCP connections
client -> server:22 and server ->server:1023 and an end-to-end ssh
connection from the client to the sshd on port 1023.
> ssh admin at 127.0.0.1 -p 1023 should work. I have shared sshd logs , can
you
> see if it gives hint on why reading passwd happens in sshd side and echo
and
> read for user happens at client side.
Looking at the debug log I think it might be a bug in sshd.  The log
says it's 6.6, which is a few years old.  Is it an unmodified version
built from the source from openssh.com, and does the current release
(7.4) do the same thing?

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Thanks Darren.

So user has to run the following command  (alternatively, he can change
.ssh/config)

ssh -o ProxyCommand='ssh -W localhost:1023 customuser at 10.220.167.184'
admin at 10.220.167.184

It works.
But is it possible to change sshd_config (server side settings) , so that
user (from client side) has to just type and at server side, we add code to
prompt user name , something like this:

ssh cliuser at 10.220.167.184
Username: admin
password:


I am trying alternatives, any quick hint would really help.

Thanks !!!




On Wed, Feb 1, 2017 at 3:26 AM, Darren Tucker <dtucker at zip.com.au>
wrote:
> On Wed, Feb 1, 2017 at 6:05 AM, Sudarshan Soma <sudarshan12s at
gmail.com>
> wrote:
> > Hi Darren,  the clients config would need customer to change firewall
> > settings to allow 1023 port.
>
> Not in the configuration I proposed: the first ssh command runs the
> second to connect to the server so you'd end up with TCP connections
> client -> server:22 and server ->server:1023 and an end-to-end ssh
> connection from the client to the sshd on port 1023.
>
> > ssh admin at 127.0.0.1 -p 1023 should work. I have shared sshd logs ,
can
> you
> > see if it gives hint on why reading passwd happens in sshd side and
echo
> and
> > read for user happens at client side.
>
> Looking at the debug log I think it might be a bug in sshd.  The log
> says it's 6.6, which is a few years old.  Is it an unmodified version
> built from the source from openssh.com, and does the current release
> (7.4) do the same thing?
>
> --
> Darren Tucker (dtucker at zip.com.au)
> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
>     Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
>