If you can access it via SSH, you can mount it on your filesystem, giving you secure access to your favorite stuff.
Samba has transformed how Penguinistas interact on networks with Windows machines and even other Linux boxes. In particular, I often use smbfs (short for "Samba filesystem") to mount a Samba share on my box for easy access. For example, I have two computers on my network: a server named sophocles and a laptop named euripides. A huge collection of music can be found on sophocles at /var/music, but I want easy access to those goodies from euripides. Using Samba on sophocles, I share /var/music, and using smbfs on euripides, I mount /var/music on my server sophocles to /home/scott/tunes on my laptop euripides. By doing so, it appears to me while I'm using euripides as though tunes is just another local folder on my laptop, so I can read files from it, save to it, and do anything else I could if that folder were in fact on my machine.
This is great, except that there are some issues. Setting up Samba can be a royal pain, so any time I can use something simpler, I jump at the chance. Second, Samba shares aren't secure by default. Call me paranoid, but I don't like anything flowing over a network that isn't encrypted. Yes, it's possible to tunnel Samba using SSH, but that just adds more time and trouble on top of the royal pain that Samba sometimes causes. Finally, Samba was designed for LANs, not the wild and woolly Internet, so accessing shares remotely is out of the question (yes, there are ways to do it, but it's just not a good idea on today's Net...and it causes yet more complication!).
But I'm here to tell you that there's a better way: sshfs, the SSH filesystem. Instead of Samba, it uses SSH. All the problems I listed previously are obviated when you switch to SSH. SSH is a breeze to set up and use. All SSH traffic is encrypted, hence the name Secure SHell. And SSH was designed for use on LANs as well as the big, bad Internet, so it's a great choice no matter where you are.
To go back to my original example, I can SSH from euripides to sophocles (and vice versa, for that matter), so I now use sshfs to mount /var/music on sophocles to /home/scott/tunes on euripides. It's easy, it's encrypted, and if this is a connection I'm going to need all the time, I can set things up in /etc/fstab to automate the whole process. Ready to try it out?
Before doing anything else, make sure that you can SSH from the client to the server:
$ ssh scott@sophocles
Linux sophocles 2.6.15-18-386 #1 PREEMPT Thu Mar 9 14:41:49 UTC 2006 i686 GNU/Linux
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
Last login: Sun Mar 12 13:59:45 2006
$ exit
If you can't SSH in, you need to set that up:
On an Ubuntu server, use sudo apt-get install ssh.
On Windows, install Cygwin, available from http://www.cygwin.com, and install OpenSSH as a service.
On the Mac, enable Remote Login in System PreferencesSharingServices.
If you can successfully SSH in to the server, you're finished with that machine (see how much simpler this is than it would be if you were using Samba?).
Now you need to focus on the local computer. Make sure you've enabled the universe archive in your /etc/apt/sources.list file, as detailed in "Modify the List of Package Repositories" [Hack #60]. Once you've done so, install sshfs:
$ sudo apt-get install sshfs
You'll be told that apt is going to have to install some additional packages in addition to sshfs (fuse-utils and libfuse2), so go ahead and approve apt's request.
When apt finishes installing your new software, it's time to fix some permissions so that normal users can mount and unmount using sshfs. If you leave out this step, mounting and unmounting will require the use of sudo and knowledge of the root password, which you probably don't want. Better to go ahead and run this command, which grants all users on your system execute permission for the fusermount command, used by sshfs to perform its magic:
$ sudo chmod +x /usr/bin/fusermount
Now you need to make the mount point you plan to use on your local machine. In my case, this would be /home/scott/tunes:
$ mkdir /home/scott/tunes
In order for sshfs to work, you have to load the fuse module. For now, go ahead and run this command:
$ sudo modprobe fuse
I know you don't want to have to run that command every time you want to mount with sshfs, so use the following command to tell Ubuntu to automatically load the fuse module when you boot:
$ sudo sh -c "echo 'fuse' >> /etc/modules"
Be very careful and use >> instead of > (in other words, append instead of overwrite)! If you accidentally use >, you will hose your box and none of your modules will load on boot. For that reason alone, you really should back up up /etc/modules first, with sudo cp /etc/modules /etc/modules_bak.
Now for the final step: mount /var/music on sophocles to /home/scott/tunes on euripides. The syntax of the command is as follows:
$ sshfs
user@
[
IP
|
HOSTNAME of remote machine
]
:/shared/path /local/mount/point
If your username is the same on the remote and local machines, you can leave it off. DNS will work either on your LAN, if you have an entry for the server in your /etc/hosts file, or over the Net to a machine with a registered address. Otherwise, use the computer's IP address. If you don't specify a path after the colon, sshfs mounts the home directory for the SSH user, which may be all that you want. In my case, my username is the same on both boxes, I have an entry for sophocles in the /etc/hosts file, and I want to mount a specific directory on the computer, so my command looks like this:
$ sshfs sophocles:/var/music /home/scott/tunes
If you get the error "fusermount: failed to open /dev/fuse: Permission denied," add yourself to the fuse group with sudo addgroup username fuse, log out, log back in again, and try the command again.
Now I can open my favorite music player, point it to /home/scott/tunes, and start enjoying jazz, rock, country, or whatever it is that floats my boat. Remember, it's all secure, so I don't have to worry about anyone sniffing packets and finding out what's moving around on my network.
To unmount, you have a choice. You can use the fusermount command with the -u option (for "unmount"):
$ fusermount -u /home/scott/tunes
Or it might be simpler just to use the good ol' umount command:
$ sudo umount /home/scott/tunes
If I knew that I wanted to make my connection to sophocles whenever I booted, I could add the following to /etc/fstab:
sophocles:/var/music /home/scott/tunes fuse defaults 0 0
The first three items are different from the usual fstab entries, with the first two exactly like the sshfs command you just used, and fuse indicating to your computer the kind of filesystem it's going to mount. If you want to change the other entries and you know what you're doing (run man fstab to learn more), go right ahead.
Once you discover sshfs, you're going to use it all the time. There's no reason not to: it works beautifully, and the added benefit of security is icing on the cake. Thank you, sshfs!
---------------------------------------------------------------------------------------------
Tested on Ubuntu 6.06 Dapper version
Tuesday, August 19, 2008
Monday, August 18, 2008
common security technique
aarklon
i have read the following in a book
at the bottom of the TCP/IP structure , in the physical and data link layers,you can encrypt data on the wire. this is one of the most common security technique used in communications.
can any one give a brief explanation of how this is done ?
Dave
The big problem with encrypting entire packets is that you give hackers a big clue because they know the physical structure of parts of the packet.If you know that the first N bytes follow recognized patterns then it can make life easier.
Think WiFi for an example.
Blackrose
I don't see a point in encrypting on the physical layer? you can view the actual transmission technique and modulation techniques as a kind of encryption i guess?
But every layer can perform encryption, each layer receives data from the layer above, and at the Data link layer, as long as both the sender and receiver can agree on a common way to scramble the data,any kind of encryption can be done. However it is a really bad idea to use complex methods on data link layer.
It is much more common to have the encryption up the top layers,closer to the actual data.. There is little point in encrypting in your application/network layer, and have that packet encrypted again in data link. The bottom layers are really only responsible for delivering data to adjacent nodes.
i have read the following in a book
at the bottom of the TCP/IP structure , in the physical and data link layers,you can encrypt data on the wire. this is one of the most common security technique used in communications.
can any one give a brief explanation of how this is done ?
Dave
The big problem with encrypting entire packets is that you give hackers a big clue because they know the physical structure of parts of the packet.If you know that the first N bytes follow recognized patterns then it can make life easier.
Think WiFi for an example.
Blackrose
I don't see a point in encrypting on the physical layer? you can view the actual transmission technique and modulation techniques as a kind of encryption i guess?
But every layer can perform encryption, each layer receives data from the layer above, and at the Data link layer, as long as both the sender and receiver can agree on a common way to scramble the data,any kind of encryption can be done. However it is a really bad idea to use complex methods on data link layer.
It is much more common to have the encryption up the top layers,closer to the actual data.. There is little point in encrypting in your application/network layer, and have that packet encrypted again in data link. The bottom layers are really only responsible for delivering data to adjacent nodes.
Thursday, August 14, 2008
remote installation
aarklon
which protocol is used in the remote installation of Linux OSes is it bootp ?
taco
yep. Bootp for the basic network ip address and tftp for downloading the
linux image.
tauno voipio
Older Suns (at least SparcStation 5, 10 and 20) use RARP instead of BOOTP for remote boot.
allen kistler
Remote boot would use bootp and tftp, for certain.Remote installation could use manual, bootp, or dhcp for address assignment, depending on the installer for the particular distro.
Content transfer typically uses nfs, ftp, http, or smb, again depending on the installer.
Strictly speaking bootp/tftp could be an option for remote installation,but it would depend on the features of the installer, and it's probably not the only option if it is available.
which protocol is used in the remote installation of Linux OSes is it bootp ?
taco
yep. Bootp for the basic network ip address and tftp for downloading the
linux image.
tauno voipio
Older Suns (at least SparcStation 5, 10 and 20) use RARP instead of BOOTP for remote boot.
allen kistler
Remote boot would use bootp and tftp, for certain.Remote installation could use manual, bootp, or dhcp for address assignment, depending on the installer for the particular distro.
Content transfer typically uses nfs, ftp, http, or smb, again depending on the installer.
Strictly speaking bootp/tftp could be an option for remote installation,but it would depend on the features of the installer, and it's probably not the only option if it is available.
/etc/aliases
sulekha
what exactly is the purpose of /etc/aliases file ?
ibutho
Its used to define aliases for mail i.e. who receives mail for certain user accounts.
what exactly is the purpose of /etc/aliases file ?
ibutho
Its used to define aliases for mail i.e. who receives mail for certain user accounts.
Wednesday, August 13, 2008
Keeping Your Desktop Time
Syncing Your Desktop to Internet Time Servers
NTP is a Network Time Protocol that connects your local machine to a remote server to configure your local time correctly. Often users do not realize that their machine is actually making these remote connections.
In order to synchronize to Internet time servers you will need to install NTP support. Choose System/Administrator/Time and Date and then select “Keep synchronized with Internet servers” Instead of Manual. If NTP support is not available you will be asked to install it by supplying your administrator password.
Once it is installed close Time and Date and then reopen if for the changes to take effect.
Note your Time zone and that the Configuration is set to Internet servers. Now it is time to Select Servers. It makes sense to select time servers that are close to you.
Select one or more time servers so that your system will synchronize with the time server on a regular basis.
Network Time Protocol is a daemon so it will listen for connections to be made to the NTP time server.Open a terminal and type:
netstat -aunt
udp 0 0 192.168.5.43:123 0.0.0.0:*
udp 0 0 127.0.0.1:123 0.0.0.0:*
udp 0 0 0.0.0.0:123 0.0.0.0:*
This shows that your Desktop is listening on port 123 for a time update from the remote Internet Servers.
The other indication that you will see is when you look at your logs in /var/log/syslog.
Jun 17 08:21:21 ub ntpd[9576]: ntpd 4.2.4p4@1.1520This e-mail address is being protected from spambots. You need JavaScript enabled to view it -o Fri Mar 7 20:24:07 UTC 2008 (1)
Jun 17 08:21:21 ub ntpd[9577]: precision = 1.000 usec
Jun 17 08:21:21 ub ntpd[9577]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
Jun 17 08:21:21 ub ntpd[9577]: Listening on interface #1 wildcard, ::#123 Disabled
Jun 17 08:21:21 ub ntpd[9577]: Listening on interface #2 lo, ::1#123 Enabled
Jun 17 08:21:21 ub ntpd[9577]: Listening on interface #3 eth0, fe80::21b:fcff:fe68:6833#123 Enabled
Jun 17 08:21:21 ub ntpd[9577]: Listening on interface #4 lo, 127.0.0.1#123 Enabled
Jun 17 08:21:21 ub ntpd[9577]: Listening on interface #5 eth0, 192.168.5.43#123 Enabled
Jun 17 08:21:21 ub ntpd[9577]: kernel time sync status 0040
Jun 17 08:25:41 ub ntpd[9577]: synchronized to 91.189.94.4, stratum 2
Jun 17 08:25:41 ub ntpd[9577]: time reset -0.209526 s
Jun 17 08:30:51 ub ntpd[9577]: synchronized to 91.189.94.4, stratum 2
From these logs you can see that the Desktop is synchronized to two separate time servers each which are stratum 2. Stratum 1 is a time server connected to an atomic clock or a radio frequency clock. So a stratum 2 gets it's time from a server that is a stratum 1 server. Each time the connection is made to the server a time offset will occur.
Enable Stats
You can view stats, which are not too useful, by enabling stats in the /etc/ntp.conf file and uncommenting the lines so it looks like this:
# Enable this if you want statistics to be logged.
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
Once you do this restart your ntp server.
# /etc/init.d/ntp restart
* Stopping NTP server ntpd [ OK ]
Starting NTP server ntpd [ OK ]
Here is a look at those stats.
54634 54912.805 91.189.94.4 9014 -0.003789257 0.215213312 7.937502568 0.000000954
54634 54913.693 131.216.22.15 9014 -0.010979699 0.102440485 7.937516505 0.000000954
Here is a helpful command to be done as root to see what server is keeping your time.
# ntpq -p
remote refid st t when poll reach delay offset jitter
================================================================
+europium.canoni 192.36.133.17 2 u 35 64 377 213.401 2.271 2.136
*egr-dns-1.egr.u 69.25.96.13 2 u 27 64 377 98.623 -6.359 1.565
The line with the * is the server that is currently used to set the clock on your Desktop.
NTP is a Network Time Protocol that connects your local machine to a remote server to configure your local time correctly. Often users do not realize that their machine is actually making these remote connections.
In order to synchronize to Internet time servers you will need to install NTP support. Choose System/Administrator/Time and Date and then select “Keep synchronized with Internet servers” Instead of Manual. If NTP support is not available you will be asked to install it by supplying your administrator password.
Once it is installed close Time and Date and then reopen if for the changes to take effect.
Note your Time zone and that the Configuration is set to Internet servers. Now it is time to Select Servers. It makes sense to select time servers that are close to you.
Select one or more time servers so that your system will synchronize with the time server on a regular basis.
Network Time Protocol is a daemon so it will listen for connections to be made to the NTP time server.Open a terminal and type:
netstat -aunt
udp 0 0 192.168.5.43:123 0.0.0.0:*
udp 0 0 127.0.0.1:123 0.0.0.0:*
udp 0 0 0.0.0.0:123 0.0.0.0:*
This shows that your Desktop is listening on port 123 for a time update from the remote Internet Servers.
The other indication that you will see is when you look at your logs in /var/log/syslog.
Jun 17 08:21:21 ub ntpd[9576]: ntpd 4.2.4p4@1.1520This e-mail address is being protected from spambots. You need JavaScript enabled to view it -o Fri Mar 7 20:24:07 UTC 2008 (1)
Jun 17 08:21:21 ub ntpd[9577]: precision = 1.000 usec
Jun 17 08:21:21 ub ntpd[9577]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
Jun 17 08:21:21 ub ntpd[9577]: Listening on interface #1 wildcard, ::#123 Disabled
Jun 17 08:21:21 ub ntpd[9577]: Listening on interface #2 lo, ::1#123 Enabled
Jun 17 08:21:21 ub ntpd[9577]: Listening on interface #3 eth0, fe80::21b:fcff:fe68:6833#123 Enabled
Jun 17 08:21:21 ub ntpd[9577]: Listening on interface #4 lo, 127.0.0.1#123 Enabled
Jun 17 08:21:21 ub ntpd[9577]: Listening on interface #5 eth0, 192.168.5.43#123 Enabled
Jun 17 08:21:21 ub ntpd[9577]: kernel time sync status 0040
Jun 17 08:25:41 ub ntpd[9577]: synchronized to 91.189.94.4, stratum 2
Jun 17 08:25:41 ub ntpd[9577]: time reset -0.209526 s
Jun 17 08:30:51 ub ntpd[9577]: synchronized to 91.189.94.4, stratum 2
From these logs you can see that the Desktop is synchronized to two separate time servers each which are stratum 2. Stratum 1 is a time server connected to an atomic clock or a radio frequency clock. So a stratum 2 gets it's time from a server that is a stratum 1 server. Each time the connection is made to the server a time offset will occur.
Enable Stats
You can view stats, which are not too useful, by enabling stats in the /etc/ntp.conf file and uncommenting the lines so it looks like this:
# Enable this if you want statistics to be logged.
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
Once you do this restart your ntp server.
# /etc/init.d/ntp restart
* Stopping NTP server ntpd [ OK ]
Starting NTP server ntpd [ OK ]
Here is a look at those stats.
54634 54912.805 91.189.94.4 9014 -0.003789257 0.215213312 7.937502568 0.000000954
54634 54913.693 131.216.22.15 9014 -0.010979699 0.102440485 7.937516505 0.000000954
Here is a helpful command to be done as root to see what server is keeping your time.
# ntpq -p
remote refid st t when poll reach delay offset jitter
================================================================
+europium.canoni 192.36.133.17 2 u 35 64 377 213.401 2.271 2.136
*egr-dns-1.egr.u 69.25.96.13 2 u 27 64 377 98.623 -6.359 1.565
The line with the * is the server that is currently used to set the clock on your Desktop.
.rhosts and /etc/hosts.equiv
aarklon
can any one give an example for configuring .rhosts file so that i can allow some trusted computers in my LAN to access my ubuntu 8.04 machine via telnet,ssh without having to enter password. BTW there is no /etc/hosts.equiv file in my machine, so will i have to create it ...????
bit twister
Easy enough, FQDN space user name per line or ip_addy user name.
$ cat ~/.rhosts
wb.home.invalid bittwister
Be sure to chmod 600 ~/.rhosts
antonio batovanja
man ssh-keygen
man ssh-copy-id
unruh
It is a bad idea to use telnet. Too many systems have had passwords stolen.That the remote computers (or local computers) are trusted is irrelevant.You also have to trust every inch of lan as well.On ssh, use the authorized-key mechanism. Place the contents of .ssh/id_rsa/pub into the other computer's .ssh/authorized_keys file to allow you to log onto their system without a password. That replaces teh notion of .rhosts or /etc/hosts.equiv
>BTW there is no /etc/hosts.equiv file in my machine, so will i have to
>create it ...????
Yes, you would have to create it if instead of listening to everyone you decided to go that route.
kcarun
I am preparing for SUN certification. In my text book in review section there is a question,
Q)Which of the following files gives a specified user permission to log in remotely from the specified host without having to supply a password?
a) .rhosts
b) /etc/hosts.equiv
c) /etc/default/login
d)/etc/hosts
1) Answer is shown as option 'a' , But 'b' is also correct?
2) these 2 files are using for same purpose ?
jrtayloriv
/etc/hosts.equiv is system-wide and applies to everyone, while .rhosts is specific to the user (and is stored in their home directory).since it says "specified user" -- the answer is (a).
javier
.rhosts can be edited by either root or a regular user in their own home directories. /etc/hosts.equiv can only be edited for root but it applies to users only.
Examples:
root on server1 wants to allow root on server2 to log into server1 as root
echo server2 >> /.rhosts
root on server1 wants root from anywhere to log in as root from any other machine (really stupid)
echo + >> /.rhosts
root on server1 wants paul to log in as root from server2 (with the -l option)
echo server2 paul >> /.rhosts
root on server1 wants to allow john and paul to log in as themselves (basically any users that exist on both machines but not root) from server2 into server1
echo server2 >> /etc/hosts.equiv
john on server1 wants john to log in as himself from server2
echo server2 >> /export/home/john/.rhosts
john on server1 wants paul to log in as john from server2
echo server2 paul >> /export/home/john/.rhosts
Well, you get the idea (I hope)
can any one give an example for configuring .rhosts file so that i can allow some trusted computers in my LAN to access my ubuntu 8.04 machine via telnet,ssh without having to enter password. BTW there is no /etc/hosts.equiv file in my machine, so will i have to create it ...????
bit twister
Easy enough, FQDN space user name per line or ip_addy user name.
$ cat ~/.rhosts
wb.home.invalid bittwister
Be sure to chmod 600 ~/.rhosts
antonio batovanja
man ssh-keygen
man ssh-copy-id
unruh
It is a bad idea to use telnet. Too many systems have had passwords stolen.That the remote computers (or local computers) are trusted is irrelevant.You also have to trust every inch of lan as well.On ssh, use the authorized-key mechanism. Place the contents of .ssh/id_rsa/pub into the other computer's .ssh/authorized_keys file to allow you to log onto their system without a password. That replaces teh notion of .rhosts or /etc/hosts.equiv
>BTW there is no /etc/hosts.equiv file in my machine, so will i have to
>create it ...????
Yes, you would have to create it if instead of listening to everyone you decided to go that route.
kcarun
I am preparing for SUN certification. In my text book in review section there is a question,
Q)Which of the following files gives a specified user permission to log in remotely from the specified host without having to supply a password?
a) .rhosts
b) /etc/hosts.equiv
c) /etc/default/login
d)/etc/hosts
1) Answer is shown as option 'a' , But 'b' is also correct?
2) these 2 files are using for same purpose ?
jrtayloriv
/etc/hosts.equiv is system-wide and applies to everyone, while .rhosts is specific to the user (and is stored in their home directory).since it says "specified user" -- the answer is (a).
javier
.rhosts can be edited by either root or a regular user in their own home directories. /etc/hosts.equiv can only be edited for root but it applies to users only.
Examples:
root on server1 wants to allow root on server2 to log into server1 as root
echo server2 >> /.rhosts
root on server1 wants root from anywhere to log in as root from any other machine (really stupid)
echo + >> /.rhosts
root on server1 wants paul to log in as root from server2 (with the -l option)
echo server2 paul >> /.rhosts
root on server1 wants to allow john and paul to log in as themselves (basically any users that exist on both machines but not root) from server2 into server1
echo server2 >> /etc/hosts.equiv
john on server1 wants john to log in as himself from server2
echo server2 >> /export/home/john/.rhosts
john on server1 wants paul to log in as john from server2
echo server2 paul >> /export/home/john/.rhosts
Well, you get the idea (I hope)
NFS locking/ concurrency control
aarklon
what exactly is the locking /concurrency control mechanism used in NFS to prevent simultaneous updates in NFS ?
antonio batovanja
man nfs" would show you:
"The Network Lock Manager protocol is a separate sideband protocol used to manage file locks in NFS version 2 and version 3. To support lock recovery after a client or server reboot, a second sideband protocol -- known as the Network Status Manager protocol -- is also required.In NFS version 4, file locking is supported directly in the main NFS protocol, and the NLM and NSM sideband protocols are not used."
david schwarz
There is no need. If the updates are simultaneous, then neither is "more recent" than the other. So it doesn't matter. It only matters if a less recent update overwrites a more recent update.
maxwell lol
Some systems have/had a lock daemon running, and the NFS implementations coordinated with them to ensure concurrency.
what exactly is the locking /concurrency control mechanism used in NFS to prevent simultaneous updates in NFS ?
antonio batovanja
man nfs" would show you:
"The Network Lock Manager protocol is a separate sideband protocol used to manage file locks in NFS version 2 and version 3. To support lock recovery after a client or server reboot, a second sideband protocol -- known as the Network Status Manager protocol -- is also required.In NFS version 4, file locking is supported directly in the main NFS protocol, and the NLM and NSM sideband protocols are not used."
david schwarz
There is no need. If the updates are simultaneous, then neither is "more recent" than the other. So it doesn't matter. It only matters if a less recent update overwrites a more recent update.
maxwell lol
Some systems have/had a lock daemon running, and the NFS implementations coordinated with them to ensure concurrency.
Subscribe to:
Posts (Atom)