sshd custom shell script for specifc user
Sudarshan Soma
sudarshan12s at gmail.com
Wed Feb 1 06:05:36 AEDT 2017
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.
>
More information about the openssh-unix-dev
mailing list