When upgrading to a newer Dlink Router, I had the problem of no longer being able to connect to SQL SVR between computers on my network (plugged into the Dlink Router).
I found the solution on this forum.
Disabling "Advanced DNS Service". Enabled is the default.
(Setup > Internet > Manual Internet Connection Setup > Advanced DNS Service)
According to the post that I found, it also resolves difficulties connecting RDP. The was some speculation that the SQL SVR connection requests were being sent out to OpenDNS thus preventing the desired connection.
For SQL SVR 2008, there is some additional Surface area configuration needed to allow connections including connections to named instances.
Note that with Open DNS turned on, you can enable local SQL SVR connections using the port forwarding settings of the Dlink Router. If you turn off Open DNS, the port forwarding settings are not required for connections between computers on your network. If you want to allow SQL SVR connections from the Internet to computers on your DLink Network, you need to configure this in Virtual Server settings (not Port Forwarding). Both Port forwarding and Virtual Server are found on the advanced tab.
My Router is less than a year old (DIR 655)
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 ...
Best Answer
I tried to think about how to tidy your question up, but don't have time. I can answer it for you: You need the 'ExitOnForwardFailure' option set to yes.