Posted by Steve on Mon 28 Jan 2013 at 23:37
專注于為中小企業(yè)提供網(wǎng)站設(shè)計(jì)、網(wǎng)站制作服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)白朗免費(fèi)做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都,凝聚了一批互聯(lián)網(wǎng)行業(yè)人才,有力地推動(dòng)了1000+企業(yè)的穩(wěn)健成長(zhǎng),幫助中小企業(yè)通過(guò)網(wǎng)站建設(shè)實(shí)現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。
Many people use SSH keys for password-less logins, and the increase in security that keys provide over (traditionally weaker) passwords. But few people seem to realize that you can also restrict logins to known-good IP addresses, via that same mechanism.
It has to be said that if you've got root access upon a server one way to restrict people connecting to your machine is to use a firewall. The venerable iptables firewall primitive makes this easy.
However you can usefully use IP address restrictions even in combination with a firewall, for example you might wish to allow your users to login from within your network, but only allow an auto-build user to login from a remote jenkins server - to clone some source code, for example.
The basic mechanism is straight-forward enough, rather than just storing the public-part of a key to your users ~/.ssh/authorized_keys file you also store some configuration entries.
To restrict the user bob to remote logins from the single IP address 1.2.3.4 you would use this in the ~bob/.ssh/authorized_keys file:
from="1.2.3.4" ssh-rsa ....
Here we've added the "from="1.2.3.4"" section, prior to the key for the user. This is just one of the options you can add, and the quoted value is a list of comma-separated hosts from which the login will be allowed.
If you wished to allow logins from several sources you could use something like this:
from="1.2.3.0/24,44.55.66.77" ssh-rsa ...
In addition to the IP-address restrictions you can configure several other things, such as denying the use of agent-forwarding, denying the use of port-forwards, & etc.
The other options are comma-separated too, and are documented in the manpage for sshd, under the section "AUTHORIZED_KEYS FILE FORMAT". As a good example of a secure login this is a good start:
from="1.2.3.4",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-rsa ...
This disables the use of agent-forwarding, port-forwarding, etc. whilst still allowing interactive logins. If you were using SSH for special-purpose logins you could restrict things further, by denying interactive login-shells and forcing the execution of a particular command:
command="/usr/local/bin/my-prog" ssh-rsa ..
This is useful for remote backups carried out via rsync + ssh, as it can ensure that your remote user can only execute the expected command - and not anything else.