hardened gentoo - reverse ssh tunnel

[zxy]

I run a box with hardened genoo linux (server).
I can ssh to i with no problems.

I need to do the following:
from some other machine (client), i need to ssh to user somebody on server, but with ability to create a reverse tunnel.

I created a user somebody and ssh-ing to it works. but when i do

Code: Select all

ssh -l somebody -R 2222:localhost:22 server.mybox.org

on the client machine i get an error:

Code: Select all

Warning: remote port forwarding failed for listen port 2222

My problem is, that if i connect with -R ... to the root the reverse tunnel works ok, but it doesn't work when i connect with -R ... to user somebody.

I guess it's some permission thing.

Help appreciated.

[zxy]

*bump*

[Hu]

Is somebody allowed to run servers? If you are using the GRsecurity patches, you may have restricted the creation of listening sockets to privileged users. See "Socket restrictions" in the GRsecurity subsection of menuconfig.

[linuxkrn]

You must be root to bind a listening port on < 1024.

Try adding a port above 1024 and try again. (sshd_config, you can have more then one port)

Code: Select all

-R 2222:localhost:2323 foobar

[Hu]

You must be root to bind a listening port on < 1024.

Try adding a port above 1024 and try again. (sshd_config, you can have more then one port)

Code: Select all

-R 2222:localhost:2323 foobar

No, he is doing it right. According to the ssh documentation, the first number is the port to bind on the peer and the second number is the port to which the local ssh should connect when a forwarding is used. He is binding port 2222 on the remote end and directing ssh to connect to port 22 locally when the forwarding is used.

[linuxkrn]

No, he is doing it right. According to the ssh documentation, the first number is the port to bind on the peer and the second number is the port to which the local ssh should connect when a forwarding is used. He is binding port 2222 on the remote end and directing ssh to connect to port 22 locally when the forwarding is used.

Hu, if you think that binding < 1024 is incorrect, I suggest you dig in the code.

From the man page (man ssh)

-R [bind_address:]port:host:hostport
Specifies that the given port on the remote (server) host is to
be forwarded to the given host and port on the local side. This
works by allocating a socket to listen to port on the remote
side, and whenever a connection is made to this port, the connec-
tion is forwarded over the secure channel, and a connection is
made to host port hostport from the local machine.

Port forwardings can also be specified in the configuration file.
Privileged ports can be forwarded only when logging in as root on the remote machine.

Again, privileged ports are < 1024.

[truc]

again 2222>1024

[Hu]

No, he is doing it right. According to the ssh documentation, the first number is the port to bind on the peer and the second number is the port to which the local ssh should connect when a forwarding is used. He is binding port 2222 on the remote end and directing ssh to connect to port 22 locally when the forwarding is used.

Hu, if you think that binding < 1024 is incorrect, I suggest you dig in the code.

Again, privileged ports are < 1024.

Yes, ports less than 1024 are privileged. Did I ever say that he was binding a privileged port? I specifically walked through his command to show how he is not binding a privileged port. He is binding a non-privileged port and instructing ssh to connect to port 22, which is perfectly legal for a non-privileged user to do.

[manaka]

As Hu pointed, it's a grsec issue. There are some grsec special user groups that can be defined when configuring the kernel. Users belonging to this group are denied/permitted "special" things.

The *default* values for the GIDs usually conflict with the values used by useradd when creating users. Check that your unprivileged user doesn't belong to the 1002 group (socket-server).

To avoid this issues, I suggest creating the following groups before adding users (be aware that Portage may also add users/groups when emerging a package).

grsec-proc1001:
grsec-socket-server1002:
grsec-socket-client1003:
grsec-socket-all1004:
grsec-tpe1005:
grsec-audit1007:

Hope this helps!

[zxy]

Thanks for so many replies. I'll test them tonight sometime and report back..

It's pentium2 machine so it might take some time for testing.