Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I am looking into implementing SSH tunneling as a cheap VPN solution for outside users to access Intranet-only facing web applications.

I currently am using Ubuntu Server 10.04.1 64 bit with OpenSSH installed.

I am using Putty on Windows boxes to create a tunnel on a local port to my ssh server.

start putty -D 9999 mysshserver.com -N

I then use tell Firefox to use a SOCKS proxy on localhost:9999.

The -N flag will disable the interactive shell from the client side. Is there a way to do this on the server side?

Besides disabling root access, using rsa key authentication, and changing the default port; are there any other obvious security practices I should follow for this purpose? My goal is to simply be able to tunnel web traffic.

share|improve this question

4 Answers 4

up vote 8 down vote accepted

After four years this answer deserved an update. While originally I used authorized_keys myself and would probably use it still in some select cases, you can also use the central sshd_config server configuration file.

sshd_config

You can designate (for your particular use case) a group, such as proxy-only or Match individual users. In sshd_config. This is done after the global settings and revokes, repeats or refines some of the settings given in the global settings.

Note: some of the syntax/directives used in sshd_config(5) are documented in the man page for ssh_config(5). In particular make sure to read the PATTERNS section of ssh_config(5).

For a group this means your Match block would begin like this:

Match group proxy-only

You can Match the following criteria: User, Group, Host, LocalAddress, LocalPort and Address. To match several criteria simply comma-separate the criteria-pattern pairs (group proxy-only above).

Inside such a block, which is traditionally indented accordingly for brevity (but needn't to), you can then declare the settings you want to apply for the user group without having to edit every single authorized_keys file for members of that group.

The no-pty setting from authorized_keys would be mirrored by a PermitTTY no setting and command="/sbin/nologin" would become ForceCommand /sbin/nologin.

Additionally you can also set more settings to satisfy an admin's paranoia, such as chroot-ing the user into his home folder and would end up with something like this:

Match group proxy-only
    # AllowTcpForwarding no
    ChrootDirectory %h
    ForceCommand /sbin/nologin
    # GatewayPorts yes
    # KbdInteractiveAuthentication no
    # PasswordAuthentication no
    # PubkeyAuthentication yes
    # PermitRootLogin no
    PermitTTY no

(check yourself whether you need or want the commented out lines and uncomment as needed)

The %h is a token that is substituted by the user's hoe directory (%u would yield the user name and %% a percent sign). I've found ChrootDirectory particularly useful to confine my sftp-only users:

Match group sftp-only
    X11Forwarding no
    AllowTcpForwarding no
    ChrootDirectory %h
    ForceCommand internal-sftp
    PasswordAuthentication no

Please mind that only certain directives can be used in a Match block. Consult the man page sshd_config(5) for details (search for Match).

authorized_keys

NB: the part below this remark was my original answer. Meanwhile - but it also depends on the features of your exact sshd version - I would go for the method described above in most cases.

Yes you can, as fine-grained as you can assign public keys. In addition to nologin as recommended by ajdecon, I would suggest setting the following in front of the key entry in authorized_keys:

no-pty ssh-rsa ...

The no pty tells the server-side that no pseudo-terminal should be allocated for that key.

You can also force the execution of something like nologin for a particular key by prepending this:

command="/sbin/nologin",no-pty ssh-rsa ...
share|improve this answer

For any tunnelling-only user, change their login shell to /sbin/nologin. That way your user will be unable to access a shell on the server, but will still be able to run set up ssh tunnels from their client.

share|improve this answer

I know this may not be the answer you're looking for, but have you considered using OpenVPN as an alternative?

share|improve this answer

I recommend trying Tunnelier. It's a heck of a lot easier to configure/manage.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.