skip to main |
skip to sidebar
BACKGROUND
EFI is a replacement of the older BIOS. If your motherboard supports EFI, this is how you use it.
I have read a bunch of different guides/howtos, but i thought none of them were easy enough, or they where outdated. Here comes my version...
INSTRUCTIONS
EFI uses a whole partition (ESP=EFI System Partition) instead of the first 512B at the first sector as MBR does. A partition has to be reserved for that (see below).
First you need a EFI bootable device with your favorite distro on. Use a USB memory, because most (?) CD/DVD readers does not seem to boot the OS into EFI mode, and will therefore not be able to automatically install EFI.
- Create a bootable USB live "CD".
- Boot into the live CD (USB).
- Format the disk with a GPT partition table with for example gparted [screenshot 1].
(Device -> Create Partition Table... -> GPT)
- Start installation, create the desired partitions and make one of them the ESP [screenshot 2-3].
(The EFI partition choice will not appear unless the live CD is booted into EFI mode.)
The ESP does not necessarily have to be the first one in the partition table.
I choose a 16MB ESP as the last partition in the table.
- In the UEFI BIOS settings make sure all EFI bootable devices are ahead of the MBR devices in the boot order [screenshot 4].
(Otherwise the empty DVD reader can rule out the EFI compatible hd, that you've put after the DVD in the boot order and the boot will stall.)
NOTES
- If you want to be able to dualboot with MS Win, then the ESP has to be FAT32. Most linux distros choose FAT16 as default (but handles FAT32), you can either preformat the ESP with FAT32 or covert it to FAT32 later on.
SCREENSHOTS
Source( ubuntu forum)
"If we see light at the end of the tunnel, it is the light of the oncoming train" ~ Robert Lowell. Oh yes, another good quote. This post is on SSH tunneling, or as I like to call it 'Poor Man's VPN'. Contrary to the sysadmin's popular belief, SSH tunneling actually can be very valuable use for both techies and home users. I say contrary to popular belief because 'reverse tunneling' and tunneling http traffic through SSH can bypass firewalls and content filters. But this article isn't about how to violate your corporate internet use policy, it's about how to create SSH tunnels to make your life just a little bit easier.
Why SSH Tunnels instead of VPN? Well, I actually use both at home. If you have followed any of my posts on jaysonbroughton.com, I use a 3-factor authentication with OpenVPN (user name, certificate & One-Time-Password). But if I want to check on one of my servers from the house via my Android, or a computer where I don't have administrative rights (required of my custom portable OpenVPN client), or even tunnel vnc over ssh to fix a problem on my better half's Linux laptop then SSH is my backup to using VPN.
What I'll cover here today is just your basics: how to create tunnels, what the syntax means, examples of reverse tunnels and why would you use each one of them. I'll briefly go over ssh_config, but a more in-depth post on custom ssh_config's will be at a later date.
So as always, time to dispense with the necessities. I use Debian in a virtual environment so your results may vary. In this case I am using OpenSSH_5.3p1 as a Server and a mix of OpenSSH 5.X ssh clients with my examples. Before I get too far into tunneling I'll say this: If you feel the need to use SSH tunneling via http or reverse SSH tunnels to bypass your corporate firewall make sure you are not violating any of your companies Internet Acceptable Use Policy. This goes without saying, your System Administrators will hunt you down and fry you when they find that you're bypassing the content filter or setting a reverse tunnel in order to tunnel back into a server at work. As a System Administrator myself, I take immense pleasure in locating such individuals. At the very least check with your Network/System Administrator so they are not caught off-guard. LinuxJournal.com and myself are not liable for your blatant violations of your corporate policy :-) With that said, let's have some fun shall we?
Creating an SSH tunnel is actually quite easy. Figuring out what to do with it once you have learned how to create a tunnel might be slightly more difficult. So I'll give you a few use cases to get your mind churning before we get into the details of creating a tunnel. I used to travel quite a bit before kids and with a previous IT job. When I traveled I would end up in the strangest of hotel rooms (you know the kind) with even stranger wireless access points. Do you really want to connect to a wireless access point where the SSID of the hotel is missspelled? Or the airport where there appears to be quite a few open WAP's? When I'm out and about I will tunnel my http traffic through ssh on my rooted droid to my home server. If I'm on my laptop/netbook I'll open an ssh tunnel and route http traffic via socks5 so that all of my traffic is encrypted via ssh then back out to me. I wouldn't trust an open WAP as far as I can throw it. What about anything else in plain text? I've tunneled SMTP traffic on my computer back to the house when certain places I've been block outbound SMTP. Same thing goes with pop3 (of which I've recently changed over to imap-s). Other examples of ssh tunneling include X11 applications tunneled via SSH, and VNC sessions. One of the things I brought up earlier is reverse tunneling, which is..well you got it, the reverse of tunneling. In this case you create a tunnel from a server that is behind a firewall with no SSH servers to an SSH server. Then when you log into that SSH server you can re-establish the connection. What good is that you say? Well if your corporate VPN is down, or requires Windows only VPN clients but you really don't want to lug your laptop home to check on a process running when you get home you can reverse tunnel. In this case you would establish a connection from server X to your home machine. Once you arrived at the house you would re-establish the connection to server X, thus bypassing the firewall/VPN and checking on the process without having to establish a VPN connection. I do this very rarely as I feel this is bad juju, bypassing all the rules setup on my firewall and VPN is usually a last resort.
So there are your examples for SSH tunneling, now let's show you how to get 'er done.
Before we get too carried away on the client side of things there are a few things that need to be edited on the server-side of sshd.config. in /etc/ssh/sshd_config I tend to make the following changes. Before you get too carried away, make a copy of /etc/ssh/sshd_config origional file so you have a reference in case something goes horribly wrong. cp /etc/ssh/sshd_config /etc/ssh/sshd_config.orig
# Force SSH Protocol 2
Protocol 2
#Turn on Privileged Separation for security
UsePrivilegeSeparation yes
#Deny root login
PermitRootLogin no
#Do not allow empty passwords
PermitEmptyPasswords no
# Forward my X Sessions
X11Forwarding yes
X11DisplayOffset 10
# I hate Motd displays
PrintMotd no
# It's alliivee
TCPKeepAlive yes
Don't forget if you do make any changes to your sshd_config file, you need to restart your sshd service in order to make the necessary changes.
All right, lets get into switches. No no, not the switches your 'pa made you pull off the tree branch when you broke ma's favorite vase, SSH switches.
A typical SSH tunnel (without tunneling X) looks like this:
ssh -N -p 22 bob@mylinuxserver.xxx -L 2110:localhost:110
Where:
-N
= Do not execute a remote command
-p 22
= External SSH port 22. I tend to use other external SSH ports to keep skript kiddies from hitting my home SSH server
bob@mylinuxserver.xxx
= username@hostname(or ip address)
-L 2110/localhost/110
= Bind information. Broken down as such: client-port:hostname:hostport - In this example your binding POP3 on the server to your localhost port 2110
So how about some examples?