Accessing SSH on networks powered through squid might be tricky if you’re new to tunneling etc. I was blocked by Squid from sshing to remote machines and making changes to squid config as well as iptables rules didn’t do any magic.
Corkscrew helped me recently to allow ssh access through HTTP-Proxy.
All that I had to do is to get Corkscrew from its homepage. Install it the linux way as follows.
Unpack and Compile corkscrew:
tar -xzvf corkscrew.tar.gz
You’re too good till here if everything goes fine. Lets see how we can use Corkscrew on SSH.
Suggest SSH command to use proxy by adding the following line to ssh configuration file that you find in your home directory. Mostly located in $HOME/.ssh/config. If you don’t find one, create it. Couple of lines marked below should go inside the config file.
ProxyCommand corkscrew http-proxy.example.com 8080 %h %p
Replacing http-proxy.example.com with the name or address of your http proxy and possibly replacing 8080 with the port on which the proxy listens, which may be 80 or 3128 in case of squid. The %h and %p will be replaced automatically by SSH with the actual destination host and port.
These lines tell the SSH client to start corkscrew to make the actual connection to the SSH server. The Host * line says that this will be done for ALL hosts.
That is it. Now try to ssh to remote machines and see a thumbs up by your terminal prompt.
Many time this trick even works to when you want to browse your networks securely by tunneling over your remote machine for browsers.
Interesting site explaining more about Corkscrew can be found here.
Tags: configuration file, Corkscrew, linux, Squid, SSH, ssh-proxy
dd is one of the magical commands on Linux box. It has proved itself to be too useful by copying and creating files from disks, iso’s etc.
Now, while we work on some servers to take backup of some drives we use dd command to take disk image. This should be done after mounting the file system as read-only. Otherwise you might end up getting a corrupted image of the disk. You can remount the entire file system of Linux using following command.
mount -o remount ro /
Now you’re all set to take the image of this system. As the file system has been mounted as read-only, new files won’t get created and you’re in a safer zone to continue further with this task.
Following command is the syntax for taking the backup of a disk called
/dev/sda over ssh using
"if" takes the disk as argument from which data needs to be read. Target is the server name or ip of the server to which image needs to be written. In the following command
backup.img is being written into
/root folder of a remote system.
dd if=/dev/sda | ssh [email protected] "(cat >/root/backup.img)"
This will be very handy for administrators who end up facing some disk issues on servers which they manage and disks etc fail to work. Before proceeding with disaster recovery process, they might have to take the backup existing server without taking it down. If you face the similar situation, don’t forget to use dd.
Visit this link for more inputs on dd.
Caution: *(Be careful with options etc with dd, you might end-up writing the data to wrong disk or location)
The basis of using ssh without typing your password is public key based authentication. You need to generate a pair of public/private keys for this.
1. Firstly, generate your public/private keys using ssh-keygen
#ssh-keygen -t rsa
You must use the -t option to specify that you are producing keys for SSHv2 using RSA. This will generate your id_rsa and id_rsa.pub in the .ssh directory in your home directory. You can either opt for a pass phrase or simply type enter. It is recommended to use a pass phrase.
2. Now copy the id_rsa.pub to the .ssh directory of the remote host you want to log on to as authorized_keys2 .
If you have more than one host from which you want to connect to the remote host, you need to add the local host’s
id_rsa.pub as one line in the authorized_keys2 file of the remote host, i.e., you can have more than one entry. Also, you need to ‘
chmod 644 authorized_keys2‘ to make it unwritable to everybody apart from the user.
You are basically telling the
sshd daemon on the remote machine to encrypt the connection with this public key and that this key is authorized for version 2 of the ssh protocol. You can use something secure like scp for this copying.
#scp /home/username/.ssh/id_rsa.pub [email protected]
Now you can ssh without having to type in your password.
Here is a small test :
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/techfiz/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/techfiz/.ssh/id_rsa.
Your public key has been saved in /home/techfiz/.ssh/id_rsa.pub.
The key fingerprint is:
a5:b5:89:00:fa:c0:0d:33:e2:e8:0d:88:d6:7c:00:cd [email protected]
$ scp /home/techfiz/.ssh/id_rsa.pub
[email protected]′s password:
$ ssh -l techfiz 192.168.0.11