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
PermitTTY no
ForceCommand /sbin/nologin
ChrootDirectory %h
# Optionally enable these by un-commenting the needed line
# AllowTcpForwarding no
# GatewayPorts yes
# KbdInteractiveAuthentication no
# PasswordAuthentication no
# PubkeyAuthentication yes
# PermitRootLogin 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 home 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 ...
What you describe is not possible. But there's still good news:
What is possible however is to establis a Dynamic connection with the SSH Server. This will open a port on your local computer to which you can point the Proxy setting of your Browser and allow you to use the tunnel as a proxy server. But you have to type a hostname/ip and port into the browser as if the browser were running on the machine the SSH Server is on.
Command looks like this: ssh user@server.example.com -D 1234
Then point your browser's proxy to localhost:1234.
So if you tunnel into Server A, and want to connect to server B, you type into your browser whatever address you would type into a Browser running on Server A. If a browser running on server A could not connect to Server B (if the process on Server B only listens on 127.0.0.1) then you still couldn't connect. It sounds like you just have the one server, but I wanted to be sure this was clear.
If you just have the one server, you tunnel into it with the Dynamic connection, set your proxy. You will then be able to type "localhost:1234" (for example) into the browser and it will connect to the service running on the remote server on port 1234.
Securit Side Note: Never never never setup a server where root can SSH in! Serious security flaw. Create a normal user account (who is allow to su or sudo) and SSH in as that user.
Best Answer
As has been discussed,
ssh -L 8080:localhost:80 username@server.comdoesn't start a magic proxy server on the client side, it simply forwards client port 8080 to server port 80. You need to get the client web browser to connect to client port 8080, which as others and myself have said involves pointing your client web browser athttp://localhost:8080/.Your new problem is that the server is running a number of name-based virtual hosts, and you don't get the right host served to you when you don't request it from the server in the URL, which is reasonable enough.
The simplest workround is to tell your client to access the site by name, but to get the OS to lie to the browser about what IP address that host resolves to. Let us suppose that you want to access hosts
vsite1.example.comandvsite2.example.org, which are both being served on port 80 on server, via the SSH tunnel we have already set up.Edit your client-side
/etc/hostsfile to tell your OS that those hostnames resolve to127.0.0.1, with entries such asI believe there are corresponding hacks for Windows, but I don't know what they are, as I never use it.
Now you can point the client browser at
http://vsite1.example.com:8080/, the client OS will tell the browser that's on localhost, the URL will point the browser to localhost port 8080, ssh will conduct the packets sub rosa to server port 80, and client browser will ask server's web server for the right vhost.