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.
linux networking ssh openssh
|
show 6 more comments
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.
linux networking ssh openssh
Just in case, to verify the obvious: The permissions on both.ssh
and their contents are the same (You usedcp -r
, notcp -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 byuser:user
,config
andid_protected
are0600
andid_protected.pub
andknown_hosts
are0644
. The/home/user/.ssh
directory is700
and also owned byuser:user
.
– Iiridayn
Nov 21 at 19:02
probably need aForwardAgent yes
in eachHost
section at least, plus I usenc
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 viabastion
,user
@desktop
still cannot. I typically dislike usingnc
as the proxy as it tends to leave runningnc
processes onbastion
. I'll adduser
@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
|
show 6 more comments
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.
linux networking ssh openssh
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
linux networking ssh openssh
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 usedcp -r
, notcp -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 byuser:user
,config
andid_protected
are0600
andid_protected.pub
andknown_hosts
are0644
. The/home/user/.ssh
directory is700
and also owned byuser:user
.
– Iiridayn
Nov 21 at 19:02
probably need aForwardAgent yes
in eachHost
section at least, plus I usenc
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 viabastion
,user
@desktop
still cannot. I typically dislike usingnc
as the proxy as it tends to leave runningnc
processes onbastion
. I'll adduser
@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
|
show 6 more comments
Just in case, to verify the obvious: The permissions on both.ssh
and their contents are the same (You usedcp -r
, notcp -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 byuser:user
,config
andid_protected
are0600
andid_protected.pub
andknown_hosts
are0644
. The/home/user/.ssh
directory is700
and also owned byuser:user
.
– Iiridayn
Nov 21 at 19:02
probably need aForwardAgent yes
in eachHost
section at least, plus I usenc
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 viabastion
,user
@desktop
still cannot. I typically dislike usingnc
as the proxy as it tends to leave runningnc
processes onbastion
. I'll adduser
@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
|
show 6 more comments
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
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 ondesktop
, correct. 2) I am trying to go directly toprotected
fromdesktop
whether logged in asuser
orroot
, 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 fromroot
@desktop
and cannot fromuser
@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 defaultyes
on bothprotected
andbastion
in/etc/ssh/sshd_config
. I have shown 3 times now that the private keys are the same betweenroot
anduser
@desktop
. I have again putForwardAgent yes
in both entries of/root/.ssh/config
and then copied/chowned/root/.ssh
to/home/user/.ssh
and theprotected
host still shows the same result -root
@desktop
logs in fine,user
@desktop
stops atdebug1: 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
add a comment |
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
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 ondesktop
, correct. 2) I am trying to go directly toprotected
fromdesktop
whether logged in asuser
orroot
, 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 fromroot
@desktop
and cannot fromuser
@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 defaultyes
on bothprotected
andbastion
in/etc/ssh/sshd_config
. I have shown 3 times now that the private keys are the same betweenroot
anduser
@desktop
. I have again putForwardAgent yes
in both entries of/root/.ssh/config
and then copied/chowned/root/.ssh
to/home/user/.ssh
and theprotected
host still shows the same result -root
@desktop
logs in fine,user
@desktop
stops atdebug1: 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
add a comment |
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
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 ondesktop
, correct. 2) I am trying to go directly toprotected
fromdesktop
whether logged in asuser
orroot
, 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 fromroot
@desktop
and cannot fromuser
@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 defaultyes
on bothprotected
andbastion
in/etc/ssh/sshd_config
. I have shown 3 times now that the private keys are the same betweenroot
anduser
@desktop
. I have again putForwardAgent yes
in both entries of/root/.ssh/config
and then copied/chowned/root/.ssh
to/home/user/.ssh
and theprotected
host still shows the same result -root
@desktop
logs in fine,user
@desktop
stops atdebug1: 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
add a comment |
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
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
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 ondesktop
, correct. 2) I am trying to go directly toprotected
fromdesktop
whether logged in asuser
orroot
, 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 fromroot
@desktop
and cannot fromuser
@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 defaultyes
on bothprotected
andbastion
in/etc/ssh/sshd_config
. I have shown 3 times now that the private keys are the same betweenroot
anduser
@desktop
. I have again putForwardAgent yes
in both entries of/root/.ssh/config
and then copied/chowned/root/.ssh
to/home/user/.ssh
and theprotected
host still shows the same result -root
@desktop
logs in fine,user
@desktop
stops atdebug1: 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
add a comment |
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 ondesktop
, correct. 2) I am trying to go directly toprotected
fromdesktop
whether logged in asuser
orroot
, 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 fromroot
@desktop
and cannot fromuser
@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 defaultyes
on bothprotected
andbastion
in/etc/ssh/sshd_config
. I have shown 3 times now that the private keys are the same betweenroot
anduser
@desktop
. I have again putForwardAgent yes
in both entries of/root/.ssh/config
and then copied/chowned/root/.ssh
to/home/user/.ssh
and theprotected
host still shows the same result -root
@desktop
logs in fine,user
@desktop
stops atdebug1: 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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
Just in case, to verify the obvious: The permissions on both
.ssh
and their contents are the same (You usedcp -r
, notcp -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 byuser:user
,config
andid_protected
are0600
andid_protected.pub
andknown_hosts
are0644
. The/home/user/.ssh
directory is700
and also owned byuser:user
.– Iiridayn
Nov 21 at 19:02
probably need a
ForwardAgent yes
in eachHost
section at least, plus I usenc
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 viabastion
,user
@desktop
still cannot. I typically dislike usingnc
as the proxy as it tends to leave runningnc
processes onbastion
. I'll adduser
@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