I use most of these commands every day to simplify my terminal interactions with an Ubuntu development box.  This is more of a personal reference but thought I would share incase you find it useful.

This is not a post about setting up Samba shares. If that is what you are looking for then I can recommend the following book; Using Samba: A File & Print Server for Linux, Unix & Mac OS X.

Sometimes you need to be able to access a remote Samba server in a secure manner from a Windows machine.  This is a relatively simple procedure on an XP SP3 machine like mine linking into an Ubuntu server pre setup with Samba file sharing.

Windows is a little bit annoying as it binds all filesharing operations to port 139 so you cannot have more than one filesharing system in operation at once.  If you were to tunnel directly across to your Samba server it would bang heads with the Windows filesharing layer.  You could just disable file sharing in Windows but that is an in elegant method and you may need access to both Windows and remote Samba shares.  So we will need to setup a new loopback adapter with a local ip address that we can tunnel Samba request through thus allowing Windows filesharing to operate normally along side Samba.  This effectively makes Windows think that it is accessing Samba shares on a seperate machine whereas a tunnel usually acts as a port on the local machine.

Add the Loopback Adapter to the Windows client machine

1. Open up the Add Hardware control panel (Start > Control Panel > Add Hardware)
2. Click next and wait for the annoying wizard to finish hunting around your system
3. Choose ‘Yes, I have already connected the hardware’
4. Then scroll to the bottom of the ‘Installed hardware’ list box and choose ‘Add new hardware device’
5. Now choose ‘Install the hardware that I manually select from a list (Advanced)’
6. Select  ‘Network adapters’
7. Under ‘Manufacturer’ you want ‘Microsoft’
8. For ‘Network Adapter’ choose ‘Microsoft Loopback Adapter’
9. You may have a to wait a little while for the adapter to be fully installed

Set the Loopback Adapters Configuration

1. Pull up the adapters properties dialogue (Start > Control Panel > Network Connections and then right click on the adapter and choose properties)
2. Disable ‘File and Printer Sharing for Microsoft Networks’
3. Highlight ‘Internet Protocol (TCP/IP)’ and click the ‘Properties’ button
   1. Choose ‘Use the following IP address’
      1. Enter ‘10.0.0.1′ for ‘IP address’
      2. Enter ‘255.255.255.0′ for ‘Subnet mask’
   2. Click the ‘Advanced’ button and on the ‘WINS’ tab
      1. Enable ‘Enable LMHOSTS Lookup’
      2. Check ‘Disable NetBIOS over TCP/IP’
4. You will now need to restart you computer even though Windows does not prompt for this step

Configure the SSH Tunnel

1. On your PuTTY session configuration dialogue choose Connection > SSH > Tunnels
2. Check/enable ‘Local ports accept connections from other hosts’
3. In ‘Source port’ enter ‘10.0.0.1:139′
4. In ‘Destination’ enter ‘localhost:139′ (127.0.0.1:139 did not work for me)

Test and Map the Connection

In the Run command console (Start > Run) enter ‘\10.0.0.1′ and you should be presented with file explorer window containing the contents of your Samba share.

So if that worked we are ready to roll, but you can give your Samba share ’server’ a more friendly name by opening ‘C:WINDOWSsystem32driversetchosts’ in your favourite editor (Vim in my case).  Scroll to the bottom and enter the following ‘10.0.0.1    samba’.  You can now access ‘//samba’ in the same way we did above via the Run dialogue.  If you have assigned the loopback device to a different subnet then you will need use the lmhosts file in the same directory instead – please see Microsoft KB Article Q105997.

Now you can Map the Samba share like any other by using the ‘Tools’ menu in a Windows file explorer window.  In the ‘Folder’ input enter ‘\samba’ or for a home directory called simon ‘\sambasimon’ (you must have enabled home directory sharing in your Samba smb.conf (/etc/samba/smb.conf)).

As you have found this page I am sure you have accidentally hit the control+s short cut whilst inside a PuTTY shell and following that no keystrokes appear to affect the session. Basically hitting ctrl+s causes PuTTY to stop executing the stream coming in from the keyboard. It does however still listen to your keystrokes and it basically adds them to a queue.

Hitting control+q will re-open the stream execution, but it is worthwhile noting that it will also execute all the queued up commands as well!

Certificates are a useful way of restricting access to your SSH server because a user must have three things to log onto the server:

1. Username
2. Password
3. Certificate

Normally they would only need to have a password and username, which can be guess at or (potentially) brute forced. Forcing the user to supply a certificate on log on means that they must also have a tangible source of identification (without the key file they cannot log in!).

Creating the key pair

Log onto the server and run ssh-keygen and you will get asked a few questions as follows (enter a passphrase):

user@host$ sudo ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
95:60:c2:31:2e:94:cf:66:b6:fa:8b:b8:45:6c:dd:22 user@server
The key’s randomart image is:
+–[ RSA 2048]—-+
| .o+.o |
| ….+ . . |
| .o. o |
| . o*. . |
| E+o.S |
| o … |
| .. |
| o.. |
| o…o. |
+—————–+

This will generate two files:

1. id_rsa
2. id_rsa.pub

in your home directory (if you chose the defaults). They are your private and public keys respectively. The public key is the one that goes on your server and the private key is the one you use when logging into the server.

Add the public key

Now on the server run

user@server:~$ cat id_rsa.pub » ~/.ssh/authorized_keys
user@server:~$ rm id_rsa

which adds the public key to the list of authorized keys for this user.

Activate the key based authentication on the server

To edit the config run

user@server:~$ sudo vim /etc/ssh/sshd_config

Ensure that you have the following lines uncommented and set correctly in your configuration file:

RSAAuthentication yes
PubkeyAuthentication yes

If you wish to lock non-certified logins from the server then also ensure you activate the following settings:

ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

Now reload the SSH configuration to get the new settings going:

user@server:~$ sudo /etc/init.d/ssh reload

Conversion to PuTTY

PuTTY has its own private key format and the private key you created earlier now needs to be converted, which is a very simple process. Firstly you need to download the key from the server and save it to your computer.

1. Now open PuTTYgen, which comes when you install PuTTY (look in the PuTTY program files directory if there is no shortcut in the start menu).
2. Click the “Load” button and point it to the private key we downloaded earlier (depending on the file extension you gave the key file you may need to adjust the file extension filter on the PuTTY load key dialogue)
3. It will ask you for the passphrase you set when you were generating the certificates – enter it!
4. PuTTYgen should now tell you that you it has successfully imported the certificate – click ok.
5. Click the “Save private key” button and save it

Getting this to work with PuTTY

Now the new key we just saved is compatible with PuTTY we can start a new PuTTY session as usual, but don’t forget to tell PuTTY where the key file is located by looking in the Category tree menu and clicking on Connection -> SSH -> Auth. You can now click the “Browse” button and point PuTTY to the key file you just created.

Click open and a new session will load:

1. Enter your username as normal
2. When prompted; give the passphrase you gave when creating your key (do not make the mistake of using your linux user account password as it won’t work!)

A very nice article: Keeping SSH access secure

I use the following in /etc/ssh/sshd_config:
AllowUsers username
PermitRootLogin no

Which kills root login access to the server meaning you will need to login as the username provided in AllowUsers and then su to root (eg. su root) or sudo the commands if you have sudo setup (apt-get install sudo).

You may also wish to change the port through which SSH occurs by adding:
Port 2345

Where 2345 is the new port number. This will stop people from attacking through the standard port 22, which can help against script kiddies and those using pre-packaged scripts. It will however not stop someone from finding the new port via ICMP sweeps.

Kick over SSHd:
/etc/init.d/ssh restart