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@ip . I am trying to instead connect to 1023 from my server, which doesnt go to firewall, hence from my server ssh admin@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@xxxxxxxxxxx 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@127.0.0.1's password: On Tue, Jan 31, 2017 at 10:53 AM, Darren Tucker <dtucker@xxxxxxxxxx> wrote: > On Tue, Jan 31, 2017 at 3:55 PM, Sudarshan Soma <sudarshan12s@xxxxxxxxx> > 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@yourgateway > > which should allow "ssh admin@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. > _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
