Dec 212014
 

That. Was. Easy.

These are the three words that a fancy button says whenever I press it. That button was gifted by an ex-colleague of mine and it says it all! Once you did it, that was easy 🙂

Exactly when you try to configure a remote port monitoring on an HP v1910 switch. Once upon a time (and I’m really speaking about 20 years ago) a company called 3Com had a slogan saying “the network that go the distance” Then they have been bought approx 4 years ago by HP, but that philosophy remained. A philosophy which says that it does not matter if you have a small switch, but the features you need must be there. Maybe a bit hidden… maybe only from CLI.

It happens that some good 3Com switched were rebranded HP around the second half 2010. All those switches, under the name of the v1910 series, are lifetime warranted!!! If you do not believe it, just click here and insert your switch serial number.

But beside the good policies, I’ve decided to write this nice post since today I reached the nirvana of my home network: two HP 1910v switches, respectively 16 and 24 ports, configured for remote port monitoring.

Continue reading »

Oct 122014
 

Pretty long title for a pretty long work, which took me more than initially thought. And because I’ve sorted out blending multiple info from multiple sites, here we go with a unified post.

Let’s start with the goal.

I wanted to have root access to my home machine via SSH/SFTP with a strong authentication system; but I also wanted to offer to a friend of mine an access to an externally connected hard drive with a simple password.

And to keep everything more secure, I wanted to have this guy chrooted into the directory he can login.

I will not cover the strong authentication setup since there are very good instructions on their site.

To enable the strong authentication only for root, I had to modify a little bit my /etc/ssh/sshd_config file as shown below.

  • disable PAM integration, by putting a hash at the beginning of the line:
    # UsePAM yes

    This is needed since we’re going to use the Match Group directive

  • inserted the following lines below the Subsystem sftp /usr/lib/openssh/sftp-server section
    Match Group root
    ForceCommand /usr/sbin/login_duo

Save and exit, restart the ssh service and test that if you try to ssh the system, after you type in root username and the password something appears similar to what reported below:

$ ssh root@192.168.1.50
root@192.168.1.50's password: 
Duo two-factor login for root
Enter a passcode or select one of the following options:
1. Duo Push to +XX XXX XXX 1791
 2. Phone call to +XX XXX XXX 1791
 3. SMS passcodes to +XX XXX XXX 1791
Passcode or option (1-3):

Once you choose (for example) 1 and confirm on your authentication device, login will complete.

To enable chromed access for my friend without forcing him to enroll to strong auth, I have created an sftp group with the command:

groupadd sftp

Then I have him to this group with the command:

usermod -G sftp <login name>

I have also disabled his shell with the command:

usermod -s /bin/bash

and set his home directory to my external disk with the command:

usermod -d /media/external/friend

Finally I have created the following entries for sftp in /etc/ssh/sshd_config file under the Subsystem sftp /usr/lib/openssh/sftp-server section as shown below.

Match Group sftp
 ChrootDirectory /media/external/friend
 AllowTCPForwarding no
 X11Forwarding no
 ForceCommand internal-sftp

NOTABENE: the directory friend must be owned by root with 700 rights. Because my friend is part of the sftp group, to allow him to upload content I needed to create a directory upload below the directory friend and had to chown such directory to his login name as shown below:

listato

If you want to have some more background info about why you need to change ownership and set rights are mentioned, check here.

Once you complete all the editing, remember to restart the ssh service with the command

service ssh restart

Enjoy!

 

Jul 042009
 

Yesterday I found a very handy functionality in Putty: tunneling apps in SSH.

Not that I did not know that this technique exist 😉 but for the first time I tried it and worked out of the box.

The idea is to enable tunneling of insecure applications inside an established and authenticated SSH encrypted session, using Putty as a client.

Scenario in my case is that I have few web based appliances at home acting as a media center, a NAS, etc… each of them being manageable by a web based interface on various ports.

I could certainly open destination PAT on my router, but it would increase the risk… and I don’t trust level of security implemented in such systems.

Therefore I’ve done something represented in picture below

ssh tunnel

How to configure it in Putty? Well, when you launch the session to connect to SSHD Server, check in SSH options – Tunnels.

There you find the chance to add the port forwarding parameters to be set as follows:

putty-tunnels

Enjoy!