Docs/SysAdmin/Networking/SSH
From Mandriva Community Wiki
Contents |
[edit] Accessing multiple machines behind a single IP address
The thing to remember is that there can only be one machine behind port 22 of a NAT router/firewall. To overcome this restriction, each machine which is to be accessed behind the router/firewall will need its own port. There is another restriction: !SSH ports cannot be NAT'ed to another port number; they must be passed through as is, i.e. port 22 goes to host1(foo):22 and port 222 goes to host2(bar):222.
Each server needs an sshd configuration file with a different port number.
Server 1 (foo)
Use a normal /etc/ssh/sshd_config file.
Server 2 (bar)
Add a port statement to this server's /etc/ssh/sshd.config file:
Port 222
On the client, setup the ssh configuration file for each server (~/.ssh/config
Host foo Hostname mydomain.com Port 22 HostKeyAlias = foo CheckHostIP = no Host bar Hostname mydomain.com Port = 222 HostKeyAlias = bar CheckHostIP = no
To establish a connection to either server, in addition to using specific calls such as:
ssh mydomain.com # port 22 is the default ssh mydomain.com -p 222
you can now make the connections with these simplified calls:
ssh foo ssh bar
[edit] Protecting against Brute Force SSH attacks
Here is a script that will parse the log files looking for attempts to exploit an SSH server using known role accounts and weak passwords and will add the IP addresses to a blacklist that can be used to deny access. This can be run safely from a cron job to prevent ongoing attacks. You should be sure that you create an entry in hosts.allow for all IP ranges that you use to connect to your box, just in case you use the wrong password or user account and get banned from your own box.
To use this, create the sshd-block script below in the /usr/local/sbin directory. Also, do a:
mkdir /usr/local/sbin/sshd_block
#!/bin/sh
cd /usr/local/sbin
#remove old file entries
rm ./sshd_block/block.txt
rm ./sshd_block/new_block.txt
#This will parse the messages file and extract the sshd lines
grep sshd /var/log/messages | grep Failed | grep invalid >> ./sshd_block/block.txt
#This line will cut only the IP addresses out of that file
cut -d \ -f 13 ./sshd_block/block.txt | uniq >> ./sshd_block/new_block.txt
#This line will add The references from new_block.txt to the ssh.blacklist
target=`cat /usr/local/sbin/sshd_block/new_block.txt`
for i in $target; do
echo ALL:$i >> /etc/hosts.deny
done
#remove duplicate entries from ssh.blacklist
cat /etc/hosts.deny | sort | uniq > /etc/hosts.deny.new
mv /etc/hosts.deny.new /etc/hosts.deny
Notes: Someone suggested that you can add a line to hosts.deny as such: sshd: /etc/ssh.block and add all the entries into a /etc/ssh.block list but I found this was not working on my system so I prefer to drop entries into the hosts.deny file.
If you find this script is not working to create an hosts.deny file with IP addresses in it, simply issue this command:
# grep sshd /var/log/messages | grep Failed | grep invalid
and check the results. Mine are below:
Dec 22 04:09:33 hostname sshd[13364]: Failed password for invalid user root from 212.78.79.20 port 49858 ssh2
You will notice that if you count from beginning to end, the IP address is the 13th item on the line, if yours is different, simply substitute the number in the cut line of the script above. I find this more reliable on my system than other methods of extracting the IP address.
As always, if you have any trouble with this script, please feel free to contact me and I will try to help you get it working on your system.
There is another method that can be used to implement blocking which is more robust. This method employs a script called BFD (Brute Force Detection) located here: http://www.rfxnetworks.com/bfd.php .
I had to make a few changes to get this to work on my Mandriva system as it is designed for Red Hat but it does appear to work well once you get the changes made.
In the rules directory after you have installed it, change the sshd file to read:
LP="/var/log/messages"
TLOG_TF="sshd"
TRIG="3"
TMP="/usr/local/bfd/tmp"
## SSH
ARG_VAL1=`$TLOGP $LP $TLOG_TF.1 | grep sshd | grep -iwf $PATTERN_FILE | awk '{print$13":"$10}' > $TMP/.sshd`
ARG_VAL2=`$TLOGP $LP $TLOG_TF.2 | grep sshd | grep -iwf $PATTERN_FILE | grep -w "Failed" | awk '{print$13":"$10}' >> $TMP/.sshd`
ARG_VAL3=`$TLOGP $LP $TLOG_TF.3 | grep sshd | grep -iwf $PATTERN_FILE | grep -w "invalid" | tr '[]=' ' ' | awk '{print$15":"$12}' >> $TMP/.sshd`
ARG_VAL=`cat $TMP/.sshd`
For those of you using ipv6 who don't want to turn it off, you will notice that you get messages saying that BFD has banned ffff. That is the erroneous info that is being picked up due to ipv6 being installed but not being used. If you want to use the above, either turn ipv6 off, or use this set of rules instead:
## SSH
ARG_VAL1=`$TLOGP $LP $TLOG_TF.1 | grep sshd | grep -iwf $PATTERN_FILE | sed s/::ffff:// | awk '{print$13":"$10}' > $TMP/.sshd`
ARG_VAL2=`$TLOGP $LP $TLOG_TF.2 | grep sshd | grep -iwf $PATTERN_FILE | grep -w "Failed" | sed s/::ffff:// | awk '{print$13":"$10}' \
>> $TMP/.sshd`
ARG_VAL3=`$TLOGP $LP $TLOG_TF.3 | grep sshd | grep -iwf $PATTERN_FILE | grep -w "invalid" | tr '[]=' ' ' | sed s/::ffff:// | awk '{print$15":"$12}' \
>> $TMP/.sshd`
ARG_VAL=`cat $TMP/.sshd`
This will use sed to cut the erroneous info out and you should pick up good IP addresses.
Also, you will want to edit the firewall command to use something other than the advanced policy firewall that it is configured to use by default. I use shorewall so you simply change the firewall command (BCMD in /usr/local/bfd/conf.bfd) to "/sbin/shorewall drop $ATT_HOST" and it should work fine. If you also don't use Shorewall, try "iptables -A INPUT -s $ATT_HOST -j DROP", although this is untested...
NB: I haven't been able to confirm the BCMD and the config file bit, because I haven't been attacked since I found this out yesterday. If you can confirm this, please remove this comment. Personally I've not been able to use this successfully, because for some reason, bfd doesn't seem to do anything. -- Main.SimonOosthoek - 07 Sep 2005
Another note, I think using shorewall or iptables is better than using hosts.deny, since that will block the incoming attack earlier in the process. I'm currently working on a perl script that uses iptables directly to block the hosts found in /var/log/auth.log. I'll post it here if it works well. -- Main.SimonOosthoek - 07 Sep 2005
[edit] Setting up VNC to connect to a NATed internal system using an SSH tunnel
Well, here's the Expert List question that led to this page's creation ...
On Mon, 2004-08-30 at 18:34, Mark wrote:
> How can I connect to my mandrake box at work using x from home? I
> already have command-line access via ssh to a seperate linux box on
> our work network. Can VNC do this? What are the steps?
What you're looking for, then, is the "-via" option to vncviewer.
Let's assume that the box to which you can ssh in from home is called "ssh.work.net", and that your work MDK box is called "mysys" (and is known by that name to the ssh.work.net system, i.e. because there is an entry in its /etc/hosts file with mysys' name and IP address, or via a DNS lookup done from ssh.work.net). Further assuming that vncserver is up and running on mysys and is listening on port 5901, your syntax would probably look like this on the home box:
vncviewer -via [email protected] -compresslevel 7 -quality 4 mysys::5901
In the above example, your username on ssh.work.net is "user". The external IP address of the ssh box can be used in place of the "ssh.work.net" name and the internal IP address of mysys can be used in lieu of the "mysys" name, if you encounter DNS issues at either end. The values for -compresslevel and -quality are just my own suggestions for what might provide you with acceptable performance for an over-the-WAN connection such as this one; tweak them to your personal satisfaction, they're explained on the vncviewer man page.
You may also find it convenient to work in full-screen mode, by using a separate X session on your local machine for the VNC session. There are three steps that you need to take to set this up:
1) Set up passwordless ssh access to the ssh.work.net machine, by running these two commands on your home system:
ssh-keygen -t rsa
(When it asks for a passphrase, you can leave it blank; if this is too insecure for you, then by all means set a passphrase, and then edit the script below - as noted therein - to enable prompting for that passphrase before connecting.)
scp ~/.ssh/id_rsa.pub [email protected]:.ssh/newkey
Then ssh in to ssh.work.net and run this command there, then logout:
cat ~/.ssh/newkey >> ~/.ssh/authorized_keys
You should now be able to ssh in to ssh.work.net and not be prompted for your password there each time you connect.
2) Create a file on your home system containing the VNC password that your work MDK system has been configured to expect, using vncpasswd:
vncpasswd ~/.ssh/workpw
3) Save this little script as ~/vncwork, and then make it executable with chmod +x ~/vncwork:
#!/bin/sh # # vncwork - connect to work system via SSH tunnel SYSA="[email protected]" SYSB="mysys" VNCPORT="5901" VNCPW=$HOME"/.ssh/workpw" # Uncomment the next two lines if your key uses a passphrase # eval $(ssh-agent) # ssh-add xinit /usr/X11R6/bin/vncviewer -fullscreen -compresslevel 7 \ -quality 4 -passwd $VNCPW -via $SYSA $SYSB::$VNCPORT -- :1 # Uncomment the following line if your key uses a passphrase # eval $(ssh-agent -k) # end script
Adjust the four variables' definitions to suit your situation.
You can then switch to a virtual terminal (Ctrl-Alt-F1 through -F6), log in, and run ./vncwork to launch your second X session (display :1) and fill it with vncviewer in full-screen mode. To switch back to your local X session, type Ctrl-Atl-F7; to return to the VNC session, Ctrl-Alt-F8.
To end the VNC session, do not log out on that screen - that will end the session at the remote end, which is not what you want; just type Ctrl-Alt-Backspace to kill both the vncviewer and the X session itself. This will drop you back at the virtual terminal where you began; log out, and then type Ctrl-Alt-F7 to get back to your local X session.
BillMullen - 31 Aug 2004
