Can ssh via tunnel from root, can't from user account











up vote
1
down vote

favorite












I have two users on desktop - root and user. I have a bastion and a protected host. When run ssh protected as root on desktop, I connect fine. When I run ssh protected as user on desktop, I get no output - just a blank line, like it's waiting for something. However, user can log in directly to the bastion host and from there to the protected host.



Both root and user have the same contents in their .ssh directories (#cp -r ~/.ssh /home/user; chown -R user:user /home/user/.ssh).



The bastion host appears to be forwarding properly - running $(which sshd) -Ddp 10222 (per https://unix.stackexchange.com/a/128910/9583) shows the same debug1: channel 0: connected to protected port 22 line on both.



Running the same on protected shows the same output until:



debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]


The second line does not display when connecting from user on desktop.



ssh -vvv protected as user on desktop shows:



OpenSSH_7.9p1, OpenSSL 1.1.1  11 Sep 2018                                                                                                                       
debug1: Reading configuration data /home/user/.ssh/config
debug1: /home/user/.ssh/config line 1: Applying options for *
debug1: /home/user/.ssh/config line 10: Applying options for protected
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Executing proxy command: exec ssh bastion -W protected:22
debug1: identity file /home/user/.ssh/id_protected type 0
debug1: identity file /home/user/.ssh/id_protected-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: ssh_exchange_identification: 33[3g
33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H
SSH-2.0-Op
debug1: ssh_exchange_identification: enSSH_7.9


debug1: ssh_exchange_identification:
debug1: ssh_exchange_identification: 6,diffie-hellman-group14-sha1
debug1: ssh_exchange_identification: aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug1: ssh_exchange_identification: 2-256,hmac-sha2-512,hmac-sha1


As root on desktop everything is the same up until the first ssh_exchange_identification line.



My ssh config is:



Host *
ServerAliveInterval 60
IdentitiesOnly yes

Host bastion
HostName bastion.host
IdentityFile ~/.ssh/id_protected
User user

Host protected
IdentityFile ~/.ssh/id_protected
Hostname protected
User user
ProxyCommand ssh bastion -W %h:%p


I have also tried https://askubuntu.com/a/976226/427339, but I believe this doesn't apply for two reasons - 1. emptying my ~/.config/fish/fish.config made no difference, and 2. I can log in to the same user on protected from root on desktop.



All three systems are running Arch Linux. protected and desktop are both using the fish shell.



Edit:



user@bastion's ~/.ssh/config:



Host *
ServerAliveInterval 60

Host protected
User user
IdentityFile ~/.ssh/id_protected


This, as mentioned above, works fine to log into protected. /etc/hosts has an entry for protected pointing to the net-local IP - 10.x.x.x.



Edit 2:



My issue appears very similar to these:




  • https://groups.google.com/d/topic/comp.security.ssh/e1nObaX5ZWg/discussion

  • https://groups.google.com/d/topic/comp.security.ssh/_HDV0JXXQA8/discussion

  • https://groups.google.com/d/topic/comp.security.ssh/tDgwEDJKGuE/discussion


I have not yet tried the MTU workaround, and am not familiar enough with protocol analyzers to have one set up and handy right now.



Edit 3:



Adding -v to the ProxyCommand (is now ProxyCommand ssh -v bastion -W %h:%p), full output of user@desktop$ ssh protected:



OpenSSH_7.9p1, OpenSSL 1.1.1  11 Sep 2018
debug1: Reading configuration data /home/user/.ssh/config
debug1: /home/user/.ssh/config line 1: Applying options for *
debug1: /home/user/.ssh/config line 5: Applying options for bastion
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to bastion [x.x.x.x] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_protected type 0
debug1: identity file /home/user/.ssh/id_protected-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.8
debug1: match: OpenSSH_7.8 pat OpenSSH* compat 0x04000000
debug1: Authenticating to bastion:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:HfDmNOGgLrPLMsnCbyZuEuJapj+T6wrSTTiFSd+37ag
debug1: Host 'bastion' is known and matches the ECDSA host key.
debug1: Found key in /home/users/.ssh/known_hosts:3
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: Will attempt key: /home/user/.ssh/id_protected RSA SHA256:iH5F4stK+j+2/qkGJlL5D6TOEHNiwbR4jCzckI7IHaE explicit agent
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_protected RSA SHA256:iH5F4stK+j+2/qkGJlL5D6TOEHNiwbR4jCzckI7IHaE explicit agent
debug1: Server accepts key: /home/user/.ssh/id_protected RSA SHA256:iH5F4stK+j+2/qkGJlL5D6TOEHNiwbR4jCzckI7IHaE explicit agent
debug1: Authentication succeeded (publickey).
Authenticated to bastion ([x.x.x.x]:22).
debug1: channel_connect_stdio_fwd protected:22
debug1: channel 0: new [stdio-forward]
debug1: getpeername failed: Bad file descriptor
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: /home/user/.ssh/authorized_keys:3: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/user/.ssh/authorized_keys:3: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
--- very long delay; from `root` everything is the same till here, but the next line is `Last login: ...`, etc - a successful connection ---
debug1: channel 0: FORCE input drain
ssh_exchange_identification: Connection closed by remote host
debug1: channel 0: free: direct-tcpip: listening port 0 for protected port 22, connect from 127.0.0.1 port 65535 to UNKNOWN port 65536, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
Killed by signal 1.









share|improve this question
























  • Just in case, to verify the obvious: The permissions on both .ssh and their contents are the same (You used cp -r, not cp -a)? You double-checked that the owner change worked correctly?
    – dirkt
    Nov 21 at 7:06










  • @dirkt Yep, I entered the commands as pasted, except on two lines instead of with a ;. I would have gotten a different error had the directory had the wrong permissions - I don't recall it, but I've seen it before. Visual inspection just now confirms - the files are owned by user:user, config and id_protected are 0600 and id_protected.pub and known_hosts are 0644. The /home/user/.ssh directory is 700 and also owned by user:user.
    – Iiridayn
    Nov 21 at 19:02










  • probably need a ForwardAgent yes in each Host section at least, plus I use nc as the proxy.
    – strobelight
    Nov 24 at 3:26










  • @strobelight tried that - neither made any difference, separate or together. root@desktop can still log in via bastion, user@desktop still cannot. I typically dislike using nc as the proxy as it tends to leave running nc processes on bastion. I'll add user@bastion's .ssh/config to the post - it's set up so it can log in direct, so I wouldn't need agent forwarding (either way didn't make a difference though).
    – Iiridayn
    Nov 27 at 20:19










  • is the private key the same for both root and user? they don't have to be, but the corresponding public key of each must be in the .ssh/authorized_keys files.
    – strobelight
    Nov 28 at 1:35















up vote
1
down vote

favorite












I have two users on desktop - root and user. I have a bastion and a protected host. When run ssh protected as root on desktop, I connect fine. When I run ssh protected as user on desktop, I get no output - just a blank line, like it's waiting for something. However, user can log in directly to the bastion host and from there to the protected host.



Both root and user have the same contents in their .ssh directories (#cp -r ~/.ssh /home/user; chown -R user:user /home/user/.ssh).



The bastion host appears to be forwarding properly - running $(which sshd) -Ddp 10222 (per https://unix.stackexchange.com/a/128910/9583) shows the same debug1: channel 0: connected to protected port 22 line on both.



Running the same on protected shows the same output until:



debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]


The second line does not display when connecting from user on desktop.



ssh -vvv protected as user on desktop shows:



OpenSSH_7.9p1, OpenSSL 1.1.1  11 Sep 2018                                                                                                                       
debug1: Reading configuration data /home/user/.ssh/config
debug1: /home/user/.ssh/config line 1: Applying options for *
debug1: /home/user/.ssh/config line 10: Applying options for protected
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Executing proxy command: exec ssh bastion -W protected:22
debug1: identity file /home/user/.ssh/id_protected type 0
debug1: identity file /home/user/.ssh/id_protected-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: ssh_exchange_identification: 33[3g
33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H
SSH-2.0-Op
debug1: ssh_exchange_identification: enSSH_7.9


debug1: ssh_exchange_identification:
debug1: ssh_exchange_identification: 6,diffie-hellman-group14-sha1
debug1: ssh_exchange_identification: aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug1: ssh_exchange_identification: 2-256,hmac-sha2-512,hmac-sha1


As root on desktop everything is the same up until the first ssh_exchange_identification line.



My ssh config is:



Host *
ServerAliveInterval 60
IdentitiesOnly yes

Host bastion
HostName bastion.host
IdentityFile ~/.ssh/id_protected
User user

Host protected
IdentityFile ~/.ssh/id_protected
Hostname protected
User user
ProxyCommand ssh bastion -W %h:%p


I have also tried https://askubuntu.com/a/976226/427339, but I believe this doesn't apply for two reasons - 1. emptying my ~/.config/fish/fish.config made no difference, and 2. I can log in to the same user on protected from root on desktop.



All three systems are running Arch Linux. protected and desktop are both using the fish shell.



Edit:



user@bastion's ~/.ssh/config:



Host *
ServerAliveInterval 60

Host protected
User user
IdentityFile ~/.ssh/id_protected


This, as mentioned above, works fine to log into protected. /etc/hosts has an entry for protected pointing to the net-local IP - 10.x.x.x.



Edit 2:



My issue appears very similar to these:




  • https://groups.google.com/d/topic/comp.security.ssh/e1nObaX5ZWg/discussion

  • https://groups.google.com/d/topic/comp.security.ssh/_HDV0JXXQA8/discussion

  • https://groups.google.com/d/topic/comp.security.ssh/tDgwEDJKGuE/discussion


I have not yet tried the MTU workaround, and am not familiar enough with protocol analyzers to have one set up and handy right now.



Edit 3:



Adding -v to the ProxyCommand (is now ProxyCommand ssh -v bastion -W %h:%p), full output of user@desktop$ ssh protected:



OpenSSH_7.9p1, OpenSSL 1.1.1  11 Sep 2018
debug1: Reading configuration data /home/user/.ssh/config
debug1: /home/user/.ssh/config line 1: Applying options for *
debug1: /home/user/.ssh/config line 5: Applying options for bastion
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to bastion [x.x.x.x] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_protected type 0
debug1: identity file /home/user/.ssh/id_protected-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.8
debug1: match: OpenSSH_7.8 pat OpenSSH* compat 0x04000000
debug1: Authenticating to bastion:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:HfDmNOGgLrPLMsnCbyZuEuJapj+T6wrSTTiFSd+37ag
debug1: Host 'bastion' is known and matches the ECDSA host key.
debug1: Found key in /home/users/.ssh/known_hosts:3
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: Will attempt key: /home/user/.ssh/id_protected RSA SHA256:iH5F4stK+j+2/qkGJlL5D6TOEHNiwbR4jCzckI7IHaE explicit agent
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_protected RSA SHA256:iH5F4stK+j+2/qkGJlL5D6TOEHNiwbR4jCzckI7IHaE explicit agent
debug1: Server accepts key: /home/user/.ssh/id_protected RSA SHA256:iH5F4stK+j+2/qkGJlL5D6TOEHNiwbR4jCzckI7IHaE explicit agent
debug1: Authentication succeeded (publickey).
Authenticated to bastion ([x.x.x.x]:22).
debug1: channel_connect_stdio_fwd protected:22
debug1: channel 0: new [stdio-forward]
debug1: getpeername failed: Bad file descriptor
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: /home/user/.ssh/authorized_keys:3: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/user/.ssh/authorized_keys:3: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
--- very long delay; from `root` everything is the same till here, but the next line is `Last login: ...`, etc - a successful connection ---
debug1: channel 0: FORCE input drain
ssh_exchange_identification: Connection closed by remote host
debug1: channel 0: free: direct-tcpip: listening port 0 for protected port 22, connect from 127.0.0.1 port 65535 to UNKNOWN port 65536, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
Killed by signal 1.









share|improve this question
























  • Just in case, to verify the obvious: The permissions on both .ssh and their contents are the same (You used cp -r, not cp -a)? You double-checked that the owner change worked correctly?
    – dirkt
    Nov 21 at 7:06










  • @dirkt Yep, I entered the commands as pasted, except on two lines instead of with a ;. I would have gotten a different error had the directory had the wrong permissions - I don't recall it, but I've seen it before. Visual inspection just now confirms - the files are owned by user:user, config and id_protected are 0600 and id_protected.pub and known_hosts are 0644. The /home/user/.ssh directory is 700 and also owned by user:user.
    – Iiridayn
    Nov 21 at 19:02










  • probably need a ForwardAgent yes in each Host section at least, plus I use nc as the proxy.
    – strobelight
    Nov 24 at 3:26










  • @strobelight tried that - neither made any difference, separate or together. root@desktop can still log in via bastion, user@desktop still cannot. I typically dislike using nc as the proxy as it tends to leave running nc processes on bastion. I'll add user@bastion's .ssh/config to the post - it's set up so it can log in direct, so I wouldn't need agent forwarding (either way didn't make a difference though).
    – Iiridayn
    Nov 27 at 20:19










  • is the private key the same for both root and user? they don't have to be, but the corresponding public key of each must be in the .ssh/authorized_keys files.
    – strobelight
    Nov 28 at 1:35













up vote
1
down vote

favorite









up vote
1
down vote

favorite











I have two users on desktop - root and user. I have a bastion and a protected host. When run ssh protected as root on desktop, I connect fine. When I run ssh protected as user on desktop, I get no output - just a blank line, like it's waiting for something. However, user can log in directly to the bastion host and from there to the protected host.



Both root and user have the same contents in their .ssh directories (#cp -r ~/.ssh /home/user; chown -R user:user /home/user/.ssh).



The bastion host appears to be forwarding properly - running $(which sshd) -Ddp 10222 (per https://unix.stackexchange.com/a/128910/9583) shows the same debug1: channel 0: connected to protected port 22 line on both.



Running the same on protected shows the same output until:



debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]


The second line does not display when connecting from user on desktop.



ssh -vvv protected as user on desktop shows:



OpenSSH_7.9p1, OpenSSL 1.1.1  11 Sep 2018                                                                                                                       
debug1: Reading configuration data /home/user/.ssh/config
debug1: /home/user/.ssh/config line 1: Applying options for *
debug1: /home/user/.ssh/config line 10: Applying options for protected
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Executing proxy command: exec ssh bastion -W protected:22
debug1: identity file /home/user/.ssh/id_protected type 0
debug1: identity file /home/user/.ssh/id_protected-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: ssh_exchange_identification: 33[3g
33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H
SSH-2.0-Op
debug1: ssh_exchange_identification: enSSH_7.9


debug1: ssh_exchange_identification:
debug1: ssh_exchange_identification: 6,diffie-hellman-group14-sha1
debug1: ssh_exchange_identification: aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug1: ssh_exchange_identification: 2-256,hmac-sha2-512,hmac-sha1


As root on desktop everything is the same up until the first ssh_exchange_identification line.



My ssh config is:



Host *
ServerAliveInterval 60
IdentitiesOnly yes

Host bastion
HostName bastion.host
IdentityFile ~/.ssh/id_protected
User user

Host protected
IdentityFile ~/.ssh/id_protected
Hostname protected
User user
ProxyCommand ssh bastion -W %h:%p


I have also tried https://askubuntu.com/a/976226/427339, but I believe this doesn't apply for two reasons - 1. emptying my ~/.config/fish/fish.config made no difference, and 2. I can log in to the same user on protected from root on desktop.



All three systems are running Arch Linux. protected and desktop are both using the fish shell.



Edit:



user@bastion's ~/.ssh/config:



Host *
ServerAliveInterval 60

Host protected
User user
IdentityFile ~/.ssh/id_protected


This, as mentioned above, works fine to log into protected. /etc/hosts has an entry for protected pointing to the net-local IP - 10.x.x.x.



Edit 2:



My issue appears very similar to these:




  • https://groups.google.com/d/topic/comp.security.ssh/e1nObaX5ZWg/discussion

  • https://groups.google.com/d/topic/comp.security.ssh/_HDV0JXXQA8/discussion

  • https://groups.google.com/d/topic/comp.security.ssh/tDgwEDJKGuE/discussion


I have not yet tried the MTU workaround, and am not familiar enough with protocol analyzers to have one set up and handy right now.



Edit 3:



Adding -v to the ProxyCommand (is now ProxyCommand ssh -v bastion -W %h:%p), full output of user@desktop$ ssh protected:



OpenSSH_7.9p1, OpenSSL 1.1.1  11 Sep 2018
debug1: Reading configuration data /home/user/.ssh/config
debug1: /home/user/.ssh/config line 1: Applying options for *
debug1: /home/user/.ssh/config line 5: Applying options for bastion
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to bastion [x.x.x.x] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_protected type 0
debug1: identity file /home/user/.ssh/id_protected-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.8
debug1: match: OpenSSH_7.8 pat OpenSSH* compat 0x04000000
debug1: Authenticating to bastion:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:HfDmNOGgLrPLMsnCbyZuEuJapj+T6wrSTTiFSd+37ag
debug1: Host 'bastion' is known and matches the ECDSA host key.
debug1: Found key in /home/users/.ssh/known_hosts:3
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: Will attempt key: /home/user/.ssh/id_protected RSA SHA256:iH5F4stK+j+2/qkGJlL5D6TOEHNiwbR4jCzckI7IHaE explicit agent
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_protected RSA SHA256:iH5F4stK+j+2/qkGJlL5D6TOEHNiwbR4jCzckI7IHaE explicit agent
debug1: Server accepts key: /home/user/.ssh/id_protected RSA SHA256:iH5F4stK+j+2/qkGJlL5D6TOEHNiwbR4jCzckI7IHaE explicit agent
debug1: Authentication succeeded (publickey).
Authenticated to bastion ([x.x.x.x]:22).
debug1: channel_connect_stdio_fwd protected:22
debug1: channel 0: new [stdio-forward]
debug1: getpeername failed: Bad file descriptor
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: /home/user/.ssh/authorized_keys:3: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/user/.ssh/authorized_keys:3: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
--- very long delay; from `root` everything is the same till here, but the next line is `Last login: ...`, etc - a successful connection ---
debug1: channel 0: FORCE input drain
ssh_exchange_identification: Connection closed by remote host
debug1: channel 0: free: direct-tcpip: listening port 0 for protected port 22, connect from 127.0.0.1 port 65535 to UNKNOWN port 65536, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
Killed by signal 1.









share|improve this question















I have two users on desktop - root and user. I have a bastion and a protected host. When run ssh protected as root on desktop, I connect fine. When I run ssh protected as user on desktop, I get no output - just a blank line, like it's waiting for something. However, user can log in directly to the bastion host and from there to the protected host.



Both root and user have the same contents in their .ssh directories (#cp -r ~/.ssh /home/user; chown -R user:user /home/user/.ssh).



The bastion host appears to be forwarding properly - running $(which sshd) -Ddp 10222 (per https://unix.stackexchange.com/a/128910/9583) shows the same debug1: channel 0: connected to protected port 22 line on both.



Running the same on protected shows the same output until:



debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]


The second line does not display when connecting from user on desktop.



ssh -vvv protected as user on desktop shows:



OpenSSH_7.9p1, OpenSSL 1.1.1  11 Sep 2018                                                                                                                       
debug1: Reading configuration data /home/user/.ssh/config
debug1: /home/user/.ssh/config line 1: Applying options for *
debug1: /home/user/.ssh/config line 10: Applying options for protected
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Executing proxy command: exec ssh bastion -W protected:22
debug1: identity file /home/user/.ssh/id_protected type 0
debug1: identity file /home/user/.ssh/id_protected-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: ssh_exchange_identification: 33[3g
33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H 33H
SSH-2.0-Op
debug1: ssh_exchange_identification: enSSH_7.9


debug1: ssh_exchange_identification:
debug1: ssh_exchange_identification: 6,diffie-hellman-group14-sha1
debug1: ssh_exchange_identification: aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug1: ssh_exchange_identification: 2-256,hmac-sha2-512,hmac-sha1


As root on desktop everything is the same up until the first ssh_exchange_identification line.



My ssh config is:



Host *
ServerAliveInterval 60
IdentitiesOnly yes

Host bastion
HostName bastion.host
IdentityFile ~/.ssh/id_protected
User user

Host protected
IdentityFile ~/.ssh/id_protected
Hostname protected
User user
ProxyCommand ssh bastion -W %h:%p


I have also tried https://askubuntu.com/a/976226/427339, but I believe this doesn't apply for two reasons - 1. emptying my ~/.config/fish/fish.config made no difference, and 2. I can log in to the same user on protected from root on desktop.



All three systems are running Arch Linux. protected and desktop are both using the fish shell.



Edit:



user@bastion's ~/.ssh/config:



Host *
ServerAliveInterval 60

Host protected
User user
IdentityFile ~/.ssh/id_protected


This, as mentioned above, works fine to log into protected. /etc/hosts has an entry for protected pointing to the net-local IP - 10.x.x.x.



Edit 2:



My issue appears very similar to these:




  • https://groups.google.com/d/topic/comp.security.ssh/e1nObaX5ZWg/discussion

  • https://groups.google.com/d/topic/comp.security.ssh/_HDV0JXXQA8/discussion

  • https://groups.google.com/d/topic/comp.security.ssh/tDgwEDJKGuE/discussion


I have not yet tried the MTU workaround, and am not familiar enough with protocol analyzers to have one set up and handy right now.



Edit 3:



Adding -v to the ProxyCommand (is now ProxyCommand ssh -v bastion -W %h:%p), full output of user@desktop$ ssh protected:



OpenSSH_7.9p1, OpenSSL 1.1.1  11 Sep 2018
debug1: Reading configuration data /home/user/.ssh/config
debug1: /home/user/.ssh/config line 1: Applying options for *
debug1: /home/user/.ssh/config line 5: Applying options for bastion
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to bastion [x.x.x.x] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_protected type 0
debug1: identity file /home/user/.ssh/id_protected-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.8
debug1: match: OpenSSH_7.8 pat OpenSSH* compat 0x04000000
debug1: Authenticating to bastion:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:HfDmNOGgLrPLMsnCbyZuEuJapj+T6wrSTTiFSd+37ag
debug1: Host 'bastion' is known and matches the ECDSA host key.
debug1: Found key in /home/users/.ssh/known_hosts:3
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: Will attempt key: /home/user/.ssh/id_protected RSA SHA256:iH5F4stK+j+2/qkGJlL5D6TOEHNiwbR4jCzckI7IHaE explicit agent
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_protected RSA SHA256:iH5F4stK+j+2/qkGJlL5D6TOEHNiwbR4jCzckI7IHaE explicit agent
debug1: Server accepts key: /home/user/.ssh/id_protected RSA SHA256:iH5F4stK+j+2/qkGJlL5D6TOEHNiwbR4jCzckI7IHaE explicit agent
debug1: Authentication succeeded (publickey).
Authenticated to bastion ([x.x.x.x]:22).
debug1: channel_connect_stdio_fwd protected:22
debug1: channel 0: new [stdio-forward]
debug1: getpeername failed: Bad file descriptor
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: /home/user/.ssh/authorized_keys:3: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/user/.ssh/authorized_keys:3: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
--- very long delay; from `root` everything is the same till here, but the next line is `Last login: ...`, etc - a successful connection ---
debug1: channel 0: FORCE input drain
ssh_exchange_identification: Connection closed by remote host
debug1: channel 0: free: direct-tcpip: listening port 0 for protected port 22, connect from 127.0.0.1 port 65535 to UNKNOWN port 65536, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
Killed by signal 1.






linux networking ssh openssh






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 28 at 21:18

























asked Nov 20 at 23:52









Iiridayn

2131416




2131416












  • Just in case, to verify the obvious: The permissions on both .ssh and their contents are the same (You used cp -r, not cp -a)? You double-checked that the owner change worked correctly?
    – dirkt
    Nov 21 at 7:06










  • @dirkt Yep, I entered the commands as pasted, except on two lines instead of with a ;. I would have gotten a different error had the directory had the wrong permissions - I don't recall it, but I've seen it before. Visual inspection just now confirms - the files are owned by user:user, config and id_protected are 0600 and id_protected.pub and known_hosts are 0644. The /home/user/.ssh directory is 700 and also owned by user:user.
    – Iiridayn
    Nov 21 at 19:02










  • probably need a ForwardAgent yes in each Host section at least, plus I use nc as the proxy.
    – strobelight
    Nov 24 at 3:26










  • @strobelight tried that - neither made any difference, separate or together. root@desktop can still log in via bastion, user@desktop still cannot. I typically dislike using nc as the proxy as it tends to leave running nc processes on bastion. I'll add user@bastion's .ssh/config to the post - it's set up so it can log in direct, so I wouldn't need agent forwarding (either way didn't make a difference though).
    – Iiridayn
    Nov 27 at 20:19










  • is the private key the same for both root and user? they don't have to be, but the corresponding public key of each must be in the .ssh/authorized_keys files.
    – strobelight
    Nov 28 at 1:35


















  • Just in case, to verify the obvious: The permissions on both .ssh and their contents are the same (You used cp -r, not cp -a)? You double-checked that the owner change worked correctly?
    – dirkt
    Nov 21 at 7:06










  • @dirkt Yep, I entered the commands as pasted, except on two lines instead of with a ;. I would have gotten a different error had the directory had the wrong permissions - I don't recall it, but I've seen it before. Visual inspection just now confirms - the files are owned by user:user, config and id_protected are 0600 and id_protected.pub and known_hosts are 0644. The /home/user/.ssh directory is 700 and also owned by user:user.
    – Iiridayn
    Nov 21 at 19:02










  • probably need a ForwardAgent yes in each Host section at least, plus I use nc as the proxy.
    – strobelight
    Nov 24 at 3:26










  • @strobelight tried that - neither made any difference, separate or together. root@desktop can still log in via bastion, user@desktop still cannot. I typically dislike using nc as the proxy as it tends to leave running nc processes on bastion. I'll add user@bastion's .ssh/config to the post - it's set up so it can log in direct, so I wouldn't need agent forwarding (either way didn't make a difference though).
    – Iiridayn
    Nov 27 at 20:19










  • is the private key the same for both root and user? they don't have to be, but the corresponding public key of each must be in the .ssh/authorized_keys files.
    – strobelight
    Nov 28 at 1:35
















Just in case, to verify the obvious: The permissions on both .ssh and their contents are the same (You used cp -r, not cp -a)? You double-checked that the owner change worked correctly?
– dirkt
Nov 21 at 7:06




Just in case, to verify the obvious: The permissions on both .ssh and their contents are the same (You used cp -r, not cp -a)? You double-checked that the owner change worked correctly?
– dirkt
Nov 21 at 7:06












@dirkt Yep, I entered the commands as pasted, except on two lines instead of with a ;. I would have gotten a different error had the directory had the wrong permissions - I don't recall it, but I've seen it before. Visual inspection just now confirms - the files are owned by user:user, config and id_protected are 0600 and id_protected.pub and known_hosts are 0644. The /home/user/.ssh directory is 700 and also owned by user:user.
– Iiridayn
Nov 21 at 19:02




@dirkt Yep, I entered the commands as pasted, except on two lines instead of with a ;. I would have gotten a different error had the directory had the wrong permissions - I don't recall it, but I've seen it before. Visual inspection just now confirms - the files are owned by user:user, config and id_protected are 0600 and id_protected.pub and known_hosts are 0644. The /home/user/.ssh directory is 700 and also owned by user:user.
– Iiridayn
Nov 21 at 19:02












probably need a ForwardAgent yes in each Host section at least, plus I use nc as the proxy.
– strobelight
Nov 24 at 3:26




probably need a ForwardAgent yes in each Host section at least, plus I use nc as the proxy.
– strobelight
Nov 24 at 3:26












@strobelight tried that - neither made any difference, separate or together. root@desktop can still log in via bastion, user@desktop still cannot. I typically dislike using nc as the proxy as it tends to leave running nc processes on bastion. I'll add user@bastion's .ssh/config to the post - it's set up so it can log in direct, so I wouldn't need agent forwarding (either way didn't make a difference though).
– Iiridayn
Nov 27 at 20:19




@strobelight tried that - neither made any difference, separate or together. root@desktop can still log in via bastion, user@desktop still cannot. I typically dislike using nc as the proxy as it tends to leave running nc processes on bastion. I'll add user@bastion's .ssh/config to the post - it's set up so it can log in direct, so I wouldn't need agent forwarding (either way didn't make a difference though).
– Iiridayn
Nov 27 at 20:19












is the private key the same for both root and user? they don't have to be, but the corresponding public key of each must be in the .ssh/authorized_keys files.
– strobelight
Nov 28 at 1:35




is the private key the same for both root and user? they don't have to be, but the corresponding public key of each must be in the .ssh/authorized_keys files.
– strobelight
Nov 28 at 1:35










1 Answer
1






active

oldest

votes

















up vote
0
down vote













Since your protected host is behind a bastion host, you still need to go through the bastion host in order to reach it whether from a root user or normal user account.



Simply duplicate the root ssh config to the user ssh config and you should be good to go, but add a ForwardAgent yes in each Host section for both the root user and your normal user on your desktop.



Host *
ServerAliveInterval 60
IdentitiesOnly yes

Host bastion
HostName bastion.host
IdentityFile ~/.ssh/id_protected
User user
ForwardAgent yes

Host protected
IdentityFile ~/.ssh/id_protected
Hostname protected
User user
ForwardAgent yes
ProxyCommand ssh bastion -W %h:%p


The sshd_config file on the bastion as well as the protected host, usually in /etc/ssh/sshd_config, will need to have AllowAgentForwarding yes which is usually the default but worth checking. If you do have to change, then restart sshd after saving.



Hopefully the private keys are the same between root and normal user, but if not, ensure the corresponding public keys are in the .ssh/authorized_keys file on the bastion host as well as the protected host. In other words, the bastion users' .ssh/authorized_keys file has an entry (single line, 2 or 3 space-separated fields) containing the public keys of the corresponding private ones used from your desktop and so does the protected host.



If you don't have the public keys any longer, you can get them via this command:



ssh-keygen -l -f /path/to/private_key





share|improve this answer























  • That is exactly what I stated I did in my question in the second paragraph.
    – Iiridayn
    Nov 28 at 3:03










  • My understanding is you have two account on desktop, root and user and you're trying to go directly to the protected host user account from your desktop whether logged in as root or as user. ` sudo -i sum .ssh/config sum ~user/.ssh/config # above two numbers should match sum .ssh/id_protected sum ~user/.ssh/id_protected # above two numbers should match ` an ssh config on the bastion is only useful if actually logging into the bastion first.
    – strobelight
    Nov 28 at 3:14












  • 1) I have two accounts on desktop, correct. 2) I am trying to go directly to protected from desktop whether logged in as user or root, correct. 3) sudo -i sum /root/.ssh/config ~user/.ssh/config are both the same, correct. 4) sudo -i sum /root/.ssh/id_protected ~user/.ssh/id_protected are both the same, correct. This was demonstrated however in paragraph 2 of my question, however, I have repeated these steps for you and verified that I can still log in from root@desktop and cannot from user@desktop. I will leave the bastion config for now, as it might help someone else.
    – Iiridayn
    Nov 28 at 4:24










  • AllowAgentFowarding is at the default yes on both protected and bastion in /etc/ssh/sshd_config. I have shown 3 times now that the private keys are the same between root and user @ desktop. I have again put ForwardAgent yes in both entries of /root/.ssh/config and then copied/chowned /root/.ssh to /home/user/.ssh and the protected host still shows the same result - root@desktop logs in fine, user@desktop stops at debug1: SSH2_MSG_KEXINIT sent [preauth]. I am frustrated that you have now asked me to take the same steps 2 and 3 times respectively.
    – Iiridayn
    Nov 28 at 19:22











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1377135%2fcan-ssh-via-tunnel-from-root-cant-from-user-account%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
0
down vote













Since your protected host is behind a bastion host, you still need to go through the bastion host in order to reach it whether from a root user or normal user account.



Simply duplicate the root ssh config to the user ssh config and you should be good to go, but add a ForwardAgent yes in each Host section for both the root user and your normal user on your desktop.



Host *
ServerAliveInterval 60
IdentitiesOnly yes

Host bastion
HostName bastion.host
IdentityFile ~/.ssh/id_protected
User user
ForwardAgent yes

Host protected
IdentityFile ~/.ssh/id_protected
Hostname protected
User user
ForwardAgent yes
ProxyCommand ssh bastion -W %h:%p


The sshd_config file on the bastion as well as the protected host, usually in /etc/ssh/sshd_config, will need to have AllowAgentForwarding yes which is usually the default but worth checking. If you do have to change, then restart sshd after saving.



Hopefully the private keys are the same between root and normal user, but if not, ensure the corresponding public keys are in the .ssh/authorized_keys file on the bastion host as well as the protected host. In other words, the bastion users' .ssh/authorized_keys file has an entry (single line, 2 or 3 space-separated fields) containing the public keys of the corresponding private ones used from your desktop and so does the protected host.



If you don't have the public keys any longer, you can get them via this command:



ssh-keygen -l -f /path/to/private_key





share|improve this answer























  • That is exactly what I stated I did in my question in the second paragraph.
    – Iiridayn
    Nov 28 at 3:03










  • My understanding is you have two account on desktop, root and user and you're trying to go directly to the protected host user account from your desktop whether logged in as root or as user. ` sudo -i sum .ssh/config sum ~user/.ssh/config # above two numbers should match sum .ssh/id_protected sum ~user/.ssh/id_protected # above two numbers should match ` an ssh config on the bastion is only useful if actually logging into the bastion first.
    – strobelight
    Nov 28 at 3:14












  • 1) I have two accounts on desktop, correct. 2) I am trying to go directly to protected from desktop whether logged in as user or root, correct. 3) sudo -i sum /root/.ssh/config ~user/.ssh/config are both the same, correct. 4) sudo -i sum /root/.ssh/id_protected ~user/.ssh/id_protected are both the same, correct. This was demonstrated however in paragraph 2 of my question, however, I have repeated these steps for you and verified that I can still log in from root@desktop and cannot from user@desktop. I will leave the bastion config for now, as it might help someone else.
    – Iiridayn
    Nov 28 at 4:24










  • AllowAgentFowarding is at the default yes on both protected and bastion in /etc/ssh/sshd_config. I have shown 3 times now that the private keys are the same between root and user @ desktop. I have again put ForwardAgent yes in both entries of /root/.ssh/config and then copied/chowned /root/.ssh to /home/user/.ssh and the protected host still shows the same result - root@desktop logs in fine, user@desktop stops at debug1: SSH2_MSG_KEXINIT sent [preauth]. I am frustrated that you have now asked me to take the same steps 2 and 3 times respectively.
    – Iiridayn
    Nov 28 at 19:22















up vote
0
down vote













Since your protected host is behind a bastion host, you still need to go through the bastion host in order to reach it whether from a root user or normal user account.



Simply duplicate the root ssh config to the user ssh config and you should be good to go, but add a ForwardAgent yes in each Host section for both the root user and your normal user on your desktop.



Host *
ServerAliveInterval 60
IdentitiesOnly yes

Host bastion
HostName bastion.host
IdentityFile ~/.ssh/id_protected
User user
ForwardAgent yes

Host protected
IdentityFile ~/.ssh/id_protected
Hostname protected
User user
ForwardAgent yes
ProxyCommand ssh bastion -W %h:%p


The sshd_config file on the bastion as well as the protected host, usually in /etc/ssh/sshd_config, will need to have AllowAgentForwarding yes which is usually the default but worth checking. If you do have to change, then restart sshd after saving.



Hopefully the private keys are the same between root and normal user, but if not, ensure the corresponding public keys are in the .ssh/authorized_keys file on the bastion host as well as the protected host. In other words, the bastion users' .ssh/authorized_keys file has an entry (single line, 2 or 3 space-separated fields) containing the public keys of the corresponding private ones used from your desktop and so does the protected host.



If you don't have the public keys any longer, you can get them via this command:



ssh-keygen -l -f /path/to/private_key





share|improve this answer























  • That is exactly what I stated I did in my question in the second paragraph.
    – Iiridayn
    Nov 28 at 3:03










  • My understanding is you have two account on desktop, root and user and you're trying to go directly to the protected host user account from your desktop whether logged in as root or as user. ` sudo -i sum .ssh/config sum ~user/.ssh/config # above two numbers should match sum .ssh/id_protected sum ~user/.ssh/id_protected # above two numbers should match ` an ssh config on the bastion is only useful if actually logging into the bastion first.
    – strobelight
    Nov 28 at 3:14












  • 1) I have two accounts on desktop, correct. 2) I am trying to go directly to protected from desktop whether logged in as user or root, correct. 3) sudo -i sum /root/.ssh/config ~user/.ssh/config are both the same, correct. 4) sudo -i sum /root/.ssh/id_protected ~user/.ssh/id_protected are both the same, correct. This was demonstrated however in paragraph 2 of my question, however, I have repeated these steps for you and verified that I can still log in from root@desktop and cannot from user@desktop. I will leave the bastion config for now, as it might help someone else.
    – Iiridayn
    Nov 28 at 4:24










  • AllowAgentFowarding is at the default yes on both protected and bastion in /etc/ssh/sshd_config. I have shown 3 times now that the private keys are the same between root and user @ desktop. I have again put ForwardAgent yes in both entries of /root/.ssh/config and then copied/chowned /root/.ssh to /home/user/.ssh and the protected host still shows the same result - root@desktop logs in fine, user@desktop stops at debug1: SSH2_MSG_KEXINIT sent [preauth]. I am frustrated that you have now asked me to take the same steps 2 and 3 times respectively.
    – Iiridayn
    Nov 28 at 19:22













up vote
0
down vote










up vote
0
down vote









Since your protected host is behind a bastion host, you still need to go through the bastion host in order to reach it whether from a root user or normal user account.



Simply duplicate the root ssh config to the user ssh config and you should be good to go, but add a ForwardAgent yes in each Host section for both the root user and your normal user on your desktop.



Host *
ServerAliveInterval 60
IdentitiesOnly yes

Host bastion
HostName bastion.host
IdentityFile ~/.ssh/id_protected
User user
ForwardAgent yes

Host protected
IdentityFile ~/.ssh/id_protected
Hostname protected
User user
ForwardAgent yes
ProxyCommand ssh bastion -W %h:%p


The sshd_config file on the bastion as well as the protected host, usually in /etc/ssh/sshd_config, will need to have AllowAgentForwarding yes which is usually the default but worth checking. If you do have to change, then restart sshd after saving.



Hopefully the private keys are the same between root and normal user, but if not, ensure the corresponding public keys are in the .ssh/authorized_keys file on the bastion host as well as the protected host. In other words, the bastion users' .ssh/authorized_keys file has an entry (single line, 2 or 3 space-separated fields) containing the public keys of the corresponding private ones used from your desktop and so does the protected host.



If you don't have the public keys any longer, you can get them via this command:



ssh-keygen -l -f /path/to/private_key





share|improve this answer














Since your protected host is behind a bastion host, you still need to go through the bastion host in order to reach it whether from a root user or normal user account.



Simply duplicate the root ssh config to the user ssh config and you should be good to go, but add a ForwardAgent yes in each Host section for both the root user and your normal user on your desktop.



Host *
ServerAliveInterval 60
IdentitiesOnly yes

Host bastion
HostName bastion.host
IdentityFile ~/.ssh/id_protected
User user
ForwardAgent yes

Host protected
IdentityFile ~/.ssh/id_protected
Hostname protected
User user
ForwardAgent yes
ProxyCommand ssh bastion -W %h:%p


The sshd_config file on the bastion as well as the protected host, usually in /etc/ssh/sshd_config, will need to have AllowAgentForwarding yes which is usually the default but worth checking. If you do have to change, then restart sshd after saving.



Hopefully the private keys are the same between root and normal user, but if not, ensure the corresponding public keys are in the .ssh/authorized_keys file on the bastion host as well as the protected host. In other words, the bastion users' .ssh/authorized_keys file has an entry (single line, 2 or 3 space-separated fields) containing the public keys of the corresponding private ones used from your desktop and so does the protected host.



If you don't have the public keys any longer, you can get them via this command:



ssh-keygen -l -f /path/to/private_key






share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 28 at 14:28

























answered Nov 28 at 3:02









strobelight

402210




402210












  • That is exactly what I stated I did in my question in the second paragraph.
    – Iiridayn
    Nov 28 at 3:03










  • My understanding is you have two account on desktop, root and user and you're trying to go directly to the protected host user account from your desktop whether logged in as root or as user. ` sudo -i sum .ssh/config sum ~user/.ssh/config # above two numbers should match sum .ssh/id_protected sum ~user/.ssh/id_protected # above two numbers should match ` an ssh config on the bastion is only useful if actually logging into the bastion first.
    – strobelight
    Nov 28 at 3:14












  • 1) I have two accounts on desktop, correct. 2) I am trying to go directly to protected from desktop whether logged in as user or root, correct. 3) sudo -i sum /root/.ssh/config ~user/.ssh/config are both the same, correct. 4) sudo -i sum /root/.ssh/id_protected ~user/.ssh/id_protected are both the same, correct. This was demonstrated however in paragraph 2 of my question, however, I have repeated these steps for you and verified that I can still log in from root@desktop and cannot from user@desktop. I will leave the bastion config for now, as it might help someone else.
    – Iiridayn
    Nov 28 at 4:24










  • AllowAgentFowarding is at the default yes on both protected and bastion in /etc/ssh/sshd_config. I have shown 3 times now that the private keys are the same between root and user @ desktop. I have again put ForwardAgent yes in both entries of /root/.ssh/config and then copied/chowned /root/.ssh to /home/user/.ssh and the protected host still shows the same result - root@desktop logs in fine, user@desktop stops at debug1: SSH2_MSG_KEXINIT sent [preauth]. I am frustrated that you have now asked me to take the same steps 2 and 3 times respectively.
    – Iiridayn
    Nov 28 at 19:22


















  • That is exactly what I stated I did in my question in the second paragraph.
    – Iiridayn
    Nov 28 at 3:03










  • My understanding is you have two account on desktop, root and user and you're trying to go directly to the protected host user account from your desktop whether logged in as root or as user. ` sudo -i sum .ssh/config sum ~user/.ssh/config # above two numbers should match sum .ssh/id_protected sum ~user/.ssh/id_protected # above two numbers should match ` an ssh config on the bastion is only useful if actually logging into the bastion first.
    – strobelight
    Nov 28 at 3:14












  • 1) I have two accounts on desktop, correct. 2) I am trying to go directly to protected from desktop whether logged in as user or root, correct. 3) sudo -i sum /root/.ssh/config ~user/.ssh/config are both the same, correct. 4) sudo -i sum /root/.ssh/id_protected ~user/.ssh/id_protected are both the same, correct. This was demonstrated however in paragraph 2 of my question, however, I have repeated these steps for you and verified that I can still log in from root@desktop and cannot from user@desktop. I will leave the bastion config for now, as it might help someone else.
    – Iiridayn
    Nov 28 at 4:24










  • AllowAgentFowarding is at the default yes on both protected and bastion in /etc/ssh/sshd_config. I have shown 3 times now that the private keys are the same between root and user @ desktop. I have again put ForwardAgent yes in both entries of /root/.ssh/config and then copied/chowned /root/.ssh to /home/user/.ssh and the protected host still shows the same result - root@desktop logs in fine, user@desktop stops at debug1: SSH2_MSG_KEXINIT sent [preauth]. I am frustrated that you have now asked me to take the same steps 2 and 3 times respectively.
    – Iiridayn
    Nov 28 at 19:22
















That is exactly what I stated I did in my question in the second paragraph.
– Iiridayn
Nov 28 at 3:03




That is exactly what I stated I did in my question in the second paragraph.
– Iiridayn
Nov 28 at 3:03












My understanding is you have two account on desktop, root and user and you're trying to go directly to the protected host user account from your desktop whether logged in as root or as user. ` sudo -i sum .ssh/config sum ~user/.ssh/config # above two numbers should match sum .ssh/id_protected sum ~user/.ssh/id_protected # above two numbers should match ` an ssh config on the bastion is only useful if actually logging into the bastion first.
– strobelight
Nov 28 at 3:14






My understanding is you have two account on desktop, root and user and you're trying to go directly to the protected host user account from your desktop whether logged in as root or as user. ` sudo -i sum .ssh/config sum ~user/.ssh/config # above two numbers should match sum .ssh/id_protected sum ~user/.ssh/id_protected # above two numbers should match ` an ssh config on the bastion is only useful if actually logging into the bastion first.
– strobelight
Nov 28 at 3:14














1) I have two accounts on desktop, correct. 2) I am trying to go directly to protected from desktop whether logged in as user or root, correct. 3) sudo -i sum /root/.ssh/config ~user/.ssh/config are both the same, correct. 4) sudo -i sum /root/.ssh/id_protected ~user/.ssh/id_protected are both the same, correct. This was demonstrated however in paragraph 2 of my question, however, I have repeated these steps for you and verified that I can still log in from root@desktop and cannot from user@desktop. I will leave the bastion config for now, as it might help someone else.
– Iiridayn
Nov 28 at 4:24




1) I have two accounts on desktop, correct. 2) I am trying to go directly to protected from desktop whether logged in as user or root, correct. 3) sudo -i sum /root/.ssh/config ~user/.ssh/config are both the same, correct. 4) sudo -i sum /root/.ssh/id_protected ~user/.ssh/id_protected are both the same, correct. This was demonstrated however in paragraph 2 of my question, however, I have repeated these steps for you and verified that I can still log in from root@desktop and cannot from user@desktop. I will leave the bastion config for now, as it might help someone else.
– Iiridayn
Nov 28 at 4:24












AllowAgentFowarding is at the default yes on both protected and bastion in /etc/ssh/sshd_config. I have shown 3 times now that the private keys are the same between root and user @ desktop. I have again put ForwardAgent yes in both entries of /root/.ssh/config and then copied/chowned /root/.ssh to /home/user/.ssh and the protected host still shows the same result - root@desktop logs in fine, user@desktop stops at debug1: SSH2_MSG_KEXINIT sent [preauth]. I am frustrated that you have now asked me to take the same steps 2 and 3 times respectively.
– Iiridayn
Nov 28 at 19:22




AllowAgentFowarding is at the default yes on both protected and bastion in /etc/ssh/sshd_config. I have shown 3 times now that the private keys are the same between root and user @ desktop. I have again put ForwardAgent yes in both entries of /root/.ssh/config and then copied/chowned /root/.ssh to /home/user/.ssh and the protected host still shows the same result - root@desktop logs in fine, user@desktop stops at debug1: SSH2_MSG_KEXINIT sent [preauth]. I am frustrated that you have now asked me to take the same steps 2 and 3 times respectively.
– Iiridayn
Nov 28 at 19:22


















draft saved

draft discarded




















































Thanks for contributing an answer to Super User!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1377135%2fcan-ssh-via-tunnel-from-root-cant-from-user-account%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Plaza Victoria

Puebla de Zaragoza

Musa