June 17, 2009
Create SOCKS Proxy to Bypass Censorship

Using the method described in my previous article, you can easily see the benefit to bypass censorship. By using the set up previously described, you can encrypt all your traffic through the proxy and therefore appear as if you are only having one long SSH connection.

But in addition, it can be a good idea to configure firefox to use the proxy to resolve the DNS requests (in case the DNS server you are using are “filtered”). To do so, type “about:config” in the adress bar and change the setting of network.proxy.socks_remote_dns from false to true as shown below.

June 16, 2009
Access Pandora Outside the USA

If you enjoy Pandora or any content that is restricted to the USA, it is quite annoying when you cannot access it because you are out of the country (Ha! Good old Europe).

Fortunately, proxies can help you fix the problem quite easily. I used to employ GPass. It is an easy solution to use under Windows but last time I tried to start it, it couldn’t find any tunnel. There is however an alternative solution to put in place if you have a web host in the USA with SSH connection: create your own proxy tunnel.

The process is simple:

  1. Create a SSH tunnel
  2. Configure your web browser to use the tunnel.

 Create a SSH tunnel

To create a tunnel, open a console (if you are using Windows, you can use Mobaxvt that I described here) and enter the following:

ssh -ND localhost:5555 user@host.com

The options are explained below but you can have more details here.

-N      Do not execute a remote command.
-D port
Specifies a local "dynamic" application-level port forwarding.
user@host.com
Your ssh credentials and webhost address

In other words, we open a remote session and traffic will be redirected to port 5555 of our machine.

Configure your web browser

I am using firefox with the FoxyProxy extension. This extension allows to use different proxy settings depending on the websites that you are visiting. In other terms, not all your traffic need to go through your webhost… only Pandora (and whatever else you feel like).

Once the new proxy is created, configure the proxy as a SOCKS proxy v5, with the configuration given above (address: localhost, port:5555) as illustrated in the screenshot below.

Then, you can configure foxyproxy to use patterns as shown below and you should now have access to Pandora (or whatever you configure) from wherever you are.

December 11, 2008
SSH Console Under Windows

While looking for an easy (and immediate) way to get an SSH console to windows, I found MobaXVT. It is describe as a “Free portable X server with Unix/Cygwin utilities”. As the description suggest, it is actually a Cygwin encapsulation into a nice multi-tab interface that has a built-in (among other things that I didn’t test) SSH client. Anyway, if you are just looking to have an SSH client under Windows, this is a great solution if you are allergic to the Cygwin installation. This is available for free download at http://mobaxvt.mobatek.net/en/.

12:06am  |   URL: http://tmblr.co/Zha3CysDHcJ
(View comments
Filed under: ssh windows 
April 17, 2008
SSH with PAM and private / public key authentication on Lacie Edmini

Following the article where I explain how to install a SSH server on the Lacie Edmini, I will explain how to allow authentication through the use of private / public key so that you can use the method explain in this article to backup your files on your local server.

During the installation of the SSH server, we didn’t touch anything in the SSH configuration files. The result was that you could login with the root user you created during the process. The first thing I want to do is to allow a normal user to use ssh. Doing so is easy. Just open the /etc/passwd file and modify the line with the user you want to allow so that it finishes by /bin/bash or /bin/sh depending on the shell you prefer. Finally, a user allowed to connect with ssh will have a line look like:

normalUser:x:503:100:Linux User,,,:/home/normalUserDirectory:/bin/bash

The other difference is the home directory that I modified to /home/userNameDirectory instead of just /home. This step is necessary to create a directory on which the user has full rights and therefore can add and modify everything he wants. With your root user ssh access, do

mkdir /home/normalUserDirectory #create user directory
chown 503 /home/normalUserDirectory #change owner so that it is the same as in /etc/passwd
chgrp 100 /home/normalUserDirectory #change group so that it is the same as in /etc/passwd
chgrp 100 /home # change group so that it is the same as your user
chmod 750 /home

Changing the permission of the home directory is required by ssh so that the user will be allowed to connect using his private key. You then need to create a .ssh directory under /home/normalUserDirectory

mkdir /home/normalUserDirectory/.ssh

and change the permissions as we just did before.

chown 503 /home/normalUserDirectory/.ssh
chgrp 100 /home/normalUserDirectory/.ssh
chmod 700 /home/normalUserDirectory/.ssh

In your computer (Linux, Windows with Cygwin, Window with Putty), generate the keys that we will need for authentication. In a previous post, I used a dsa key:

ssh-keygen -b 1024 -f identity -P '' -t dsa

but you could use as well a rsa key:

ssh-keygen -b 2048 -f identity -P '' -t rsa

There are different ways to do it but what’s important is that you verify that the identity.pub that is generated and contains the public key has everything on one line. Verify that the user name at the end of the line is the same that the one you want to allow on the server (i.e. normalUser). Once you have ensure that the file is correct, you can transfer it to the server in the .ssh directory that we have created earlier:

scp identity.pub new_root_user@Lacie_IP_address:/home/normalUserDirectory/.ssh/authorized_keys

And then don’t forget to change owner and group of the authorized_keys file and permissions

chown 503 /home/normalUserDirectory/.ssh/authorized_keys
chgrp 100 /home/normalUserDirectory/.ssh/authorized_keys
chmod 644 /home/normalUserDirectory/.ssh/authorized_keys #you can specify 400 as well

For an alternative transfer method, look at the previous post reference above but one more time don’t forget to set the correct owner and group.

Everything is in place to use the identification with private / public key on the server. The last thing to do is to verify your /etc/ssh/sshd_config file so that it looks like the following:

#    $OpenBSD: sshd_config,v 1.74 2006/07/19 13:07:10 dtucker Exp $
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.
#Port 22
Protocol 2
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768
# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
# Allow authentication through private / public key
#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
# no default banner path
#Banner /some/path
# override default of no subsystems
Subsystem sftp /usr/lib/misc/sftp-server
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# ForceCommand cvs server

All commented lines are in fact the default value that SSHd is using. I haven’t modify it at all so it is the default file contained in the SSH package that you have downloaded from my previous post explaining how to install SSH on the Lacie Edmini.

That’s it! SSH is running and allows you to login automatically in the home directory of your normal user with:

ssh -i identity -l userNormal LACIE_IP_ADDRESS 

Of course you should specify the correct path to the private key (identity). I have noticed that I could have some problem when the public and private keys where in the same directory so since you don’t really need the public key anymore you can move it to another folder.

The normal users can now realizes their backup easily in their own directory.

March 21, 2008
Add SSH on a LaCie EdMini v2

In a previous post, I explained how to make automatic backup on a server using SSH. I was suggesting that the server was somewhere on the Internet so we didn’t have to deal with any SSH installation. However, sometimes some data are to sensible to be stocked somewhere on the Internet so a good idea is to have your own little server running SSH. In addition, once data are backuped on your local server you can decide (automatically) which one of them can be send on a distant server.

I have a Lacie Edmini V2 (ethernet gigabit disk). It is a nice little network harddrive coming with a Linux OS. It already has a Http and Ftp server but unfortunately, no SSH or rsync. Therefore, before being able to use the backup scripts we have to install these two services. Fortunately for us, some good work has already be done by some people. But unfortunately, I’m not as good with Linux as these guys are so everything they said was not always really clear. That is mainly the reason why I will try to create a guide that will be a little bit more explicit. I still assume however that you have some basic Linux knowledge.

Our starting points are the following 3 sources:

Have a look at them before we start our work and if you don’t understand everything, don’t worry… I didn’t either. Under is the list of things we are going to do to add SSH support to your Lacie Edmini.

  1. Open your drive and void the warranty (and don’t blame me or anyone else if sonething is going wrong. As usual you are doing this at your own risk!)
  2. Install the drive in another computer or in a USB case
  3. Backup the system partitions
  4. Copy the packages we will need to install
  5. Install the shell backdoor
  6. Create new user to use the packages we will install
  7. Put the disk back in place
  8. Start Telnet
  9. Install SSH
  10. Configure SSH
  11. Remove backdoor and telnet script

Alright, now that you know what we are going to do, let’s do it.

Open drive (void warranty) and install it on another computer

There is no more to explain than Jim already did in here. Have I mentionned already that you need a computer with a Linux running to do the next steps? Well if you don’t have any Linux installed, you can always do it with a live CD (have a look at Knoppix or Ubuntu).

Backup the system partitions

As I was not really comfortable to do a backup using the command line tool dd and I didn’t want to use too much space on backup, I went for a more interactive backup tool: partimage. There is not much to say here, just start the software and backup the system partitions, which are given by the 3 sources above, i-e partitions 7, 8 and 9. I recommand that you backup these partitions on another hard drive (the one of your computer for instance). In case anything goes wrong you will still have the possibility to restore the system.

Copy useful packages

Juergen Hench found that many packages compiled for other NAS drive where working on the Lacie Edmini (the list of compiled packages is available here). So copy on the partition 2 of your drive (the data partition (share/)) the following packages :

  • bzip2
  • openssh
  • openssl
  • popt
  • rsync
  • tcp-wrappers
  • zlib

You may also have to download telnet here :

http://downloads.nas-central.org/Uploads/LSPro/Binaries/utelnetd

Install the shell backdoor

The three sources explain to create a file (we will call it webshell) containing the following:

#!/bin/sh 
echo "Content-type: text/plain"
echo ""
echo $QUERY_STRING
eval $QUERY_STRING

and to put it in the partition 7 under the /www/cgi-bin/admin/ directory. Change the permission of the file to make it executable:

chmod +x /www/cgi-bin/admin/webshell

While you’re at it, change the permission of the telnet daemon that you have downloaded earlier to make it executable as well:

chmod +x /home/share/utelnetd

Create new user

While I was following the steps given by the tutorials I base my work on, I always got a problem when they create the root user that will be able to use SSH or Telnet. Unfortunately for me, each time I was using the webshell to add a user, I screwed things up but I don’t really know how or why. That’s the reason why I decided to create the new user we would need later while the drive is still connected to the computer.

Look for the passwd file (find / -name passwd). The one we are interested in is located under a “etc” directory. But you will probably find 2 of them. So the one we are interested in is not in partition 7 (but I can’t remember if it is in partition 8 or 9). It means that the path to it is something like …/snaps/00/etc/passwd. Once identified, open it with your favorite editor. If you have created other users than the admin default one then you should see them in the file. It shows that you are in the right file. So basically we will add two lines: one for a root user and one for the ssh user that is required to start openssh.

new_root:x:0:0:Linux User,,,:/home:/bin/sh
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin

Once done, we have to edit the “shadow” file located in the same directory as the passwd file and add a line for the new_root user. The “shadow” file contains the encrypted password of all users. You can copy the encrypted password of your admin account for instance or left the field blank for the moment. I copied the other values from the others lines.

new_root:encrypted_pass:12488:0:99999:7:::

Put the disk back in place and start telnet

Once your drive is reassembled and restarted, we will be able to start the Telnet daemon. To do so, just connect to your drive with your webbrowser

http://LACIE_IP_ADDRESS/cgi-bin/admin/webshell?/home/share/utelnetd

Of course, I suppose here that you have put the packages downloaded previously on the share folder of the data partition. If you have put it elsewhere, just specify the correct path. Once telnet is started, you should be able to connect to your drive through it. Open a console (or command prompt) and try

telnet new_root@LACIE_IP_ADDRESS

If you don’t have specified a password yet you should be connected right away and it is the moment to add one

passwd new_root

Install SSH

With this telnet access we can install SSH. So with the packages that you have downloaded previously just do

tar -xvjf PACKAGE.bz2 -C /

I think I haven’t forgot any packages so the service should be able to start. However if you try a /sbin/sshd it will complain about missing keys. So to correct it and allow ssh to start when the harddrive starts we will create an init script. It is based on what you have read here but modified a bit to create the keys automatically if they do not exist. So here is the file called “sshd” that you have to put under /etc/rc.d/init.d/ and / or .under …/snaps/00/etc/rc.d/init.d/

#!/bin/sh
# Begin $rc_base/init.d/
# Based on sysklogd script from LFS-3.1 and earlier.
# Rewritten by Gerard Beekmans - gerard@linuxfromscratch.org
# changed a bit by Juergen Hench to run sshd, made from httpd
# changed a bit by Jimmy B. to create the ssh keys if they do not exist already
. /etc/sysconfig/rc
. $rc_functions
. /etc/packageversion
case "$1" in
start)
echo "Starting OpenSSH sshd..."
# Start OpenSSH server
if [ ! -r /etc/ssh/ssh_host_rsa_key ]; then
/usr/bin/ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_rsa_key -N ''
fi
if [ ! -r /etc/ssh/ssh_host_dsa_key ]; then
/usr/bin/ssh-keygen -b 1024 -t dsa -f /etc/ssh/ssh_host_dsa_key -N ''
fi
/usr/sbin/sshd
evaluate_retval
;;
stop)
echo "Stopping sshd..."
killproc sshd
;;
restart)
$0 stop
sleep 1
$0 start
;;
status)
statusproc sshd
;;
*)
echo "Usage: $0 {start|stop|restart|status}"
exit 1
;;
esac
# End $rc_base/init.d/

Don’t forget to make it executable chmod +x /etc/rc.d/init.d/sshd

While we’re at it we can create already the symlinks to start automatically [Edit 2008-05-05] An error has been corrected below following a comment [/Edit]:

ln -s  ../../init.d/sshd /etc/rc.d/rc3.d/S20sshd 
ln -s ../../init.d/sshd /etc/rc.d/rc6.d/K09sshd

Alright, we are almost done. Try to start SSHd just by doing /etc/rc.d/init.d/sshd start. It shouldn’t complain anymore about missing keys, but if you try to connect using ssh and the new_root account, you may still have some problem (at least I did). I identified the problem to be coming from the PAM security module. So there is one more thing to modify. We will modify the file /etc/pam.d/sshd (taken from Suse SUSE LINUX Enterprise Server – Installation and Administration - Chapter 20. PAM — Pluggable Authentication Modules / 20.2. The PAM Configuration of sshd and modified a bit).

#%PAM-1.0
auth required pam_unix.so # set_secrpc
auth required pam_nologin.so
auth required pam_env.so
account required pam_unix.so
account required pam_nologin.so
password required pam_pwcheck.so
password required pam_unix.so use_first_pass use_authtok
session required pam_unix.so none # trace or debug
session required pam_limits.so
# Enable the following line to get resmgr support for
# ssh sessions (see /usr/share/doc/packages/resmgr/README.SuSE)
#session optional pam_resmgr.so fake_ttyname

Just create a file (pam_sshd) containing the content above and put it on your drive (in the data partition for instance). Then using you’re telnet session or the webshell, just move it properly:

cp /etc/pam.d/sshd /etc/pam.d/sshd.bak 
cp /home/share/pam_sshd /etc/pam.d/sshd
/etc/rc.d/init.d/sshd restart

Try to login again… it should work!


Remove webshell and telnet

Once ssh is working properly, you can remove the webshell backdoor and the telnet script.

That’s all I have done for the moment on this disk. I hope I have been clear enough. More can be done with this box as you have seen in the other articles I base my work on. I haven’t tried yet to use the backup method explained in another post but I will eventually. If you have any problem, you can try to post a comment and I’ll help in the limit of my time and my knowledge.

Follow up

I have written another post to allow the automatic login with SSH through the use of private / public key. It is available here.

6:22pm  |   URL: http://tmblr.co/Zha3CysD3u4
(View comments
Filed under: ssh lacie edmini 
Liked posts on Tumblr: More liked posts »