a young boy..
ovylbsLYcwc
tribute to the best….
I want to die with my forehead on the groud,
The sunnah in my heart,
Allah in my mind,
Quran on my tongue,
And tears in my eyes…
C8K-eBCmDWI
Makkah…
B1cntuRboIA
a young boy..
ovylbsLYcwc
tribute to the best….
I want to die with my forehead on the groud,
The sunnah in my heart,
Allah in my mind,
Quran on my tongue,
And tears in my eyes…
C8K-eBCmDWI
Makkah…
B1cntuRboIA
Securing Windows File Sharing Using SSH Connection Tunneling
Tunneling Windows file shares is useful if you want to comfortably access files on a Windows machine that is only accessible via SSH, and you don’t want to use SFTP or SCP.
To tunnel Windows file shares over an SSH connection, you need to forward connections on port 139 on the sharing-consumer machine via SSH to the sharing-provider machine. The exact setup differs depending on the version of Windows on the sharing-consumer machine:
* Windows 2000: configure the SSH client to listen on interface 127.0.0.2 and connect to ‘\\127.0.0.2\sharename’. This is all that is necessary.
* Windows XP: same as for Windows 2000, but before using the forwarded share, the local (client’s) Windows file sharing server needs to be stopped via ‘net stop server’. To disable it permanently, run ‘sc config lanmanserver start= disabled’. To re-enable it at a later time, run ‘sc config lanmanserver start= auto’. Note the space between ‘start= ‘ and the following parameter – sc will fail without it.
If you want to avoid disabling the file sharing server on the client machine because you want to retain remote access to the client machine’s shared resources, there is another alternative. You can install the Microsoft Loopback Adapter according to instructions relevant to your version of Windows:
* The Loopback Adapter and file share tunneling: Windows XP and 2003
* The Loopback Adapter and file share tunneling: Windows 2000
* The Loopback Adapter and file share tunneling: Windows NT4
If using the Microsoft Loopback Adapter, remember to setup your SSH client appropriately: use the Loopback Adapter’s IP instead of 127.0.0.1 or 127.0.0.2. If you assigned the Loopback Adapter the IP address 10.10.10.10, configure a client-to-server port forwarding rule to listen on 10.10.10.10, port 139; then you can connect to ‘\\10.10.10.10\sharename’.
If the instructions on this page fail for you, try some of the file share tunneling tips contributed by our users.
Note that, in all cases, you will not be able to browse to the sharing-provider machine via point-and-click – the network path needs to be typed in manually.
Step-by-step instructions
Follow these steps if you wish to get quickly up and started with Windows file sharing over SSH. It is advised that you try to understand what is being done by each one of the steps presented. The difference between understanding and not understanding is frequently the difference between a security measure which works and one that only appears to.
On the server machine: (the file-sharing provider)
1. Install WinSSHD on the server (the machine that has the resources you wish to access with Windows file sharing).
2. No changes to the default WinSSHD configuration are required to use Windows file sharing over SSH. You may wish to make changes to the default WinSSHD configuration later on, to restrict what WinSSHD features are accessible to remote users. However, for the time being, keep your WinSSHD settings at default until your file sharing over SSH is up and running.
3. Apart from installing WinSSHD, the only thing you need to do on the server is ensure that there is a Windows account which you can use to log on locally, and which you are comfortable using through Tunnelier and WinSSHD. If such an account does not yet exist, create one and use it to log on for the first time through the local Windows console to make sure all settings for the new account are initialized.
4. Start the WinSSHD service from the WinSSHD Control Panel.
On the client machine:
1. If the client is running Windows XP or 2003 and you wish to retain the ability to share the client’s resources, install and configure the Microsoft Loopback Adapter.
2. Install Tunnelier on the client (the machine from which you wish to be accessing the server machine’s shared resources).
3. Configure the following settings on the Login tab in Tunnelier. Click also the ‘Help’ link on the Login tab for help with any of these settings.
1. Host: The IP address or DNS name of the server that you are accessing.
2. Port: You will normally use the default value, 22. This must match the port that WinSSHD is listening on. If you have made no changes to the default WinSSHD configuration to change the port it is listening on, use 22.
3. Username: The Windows account name with which to log into the server. This must be a valid Windows account name with local logon permissions on the side of the server.
4. Password: The password with which to log into the server, belonging to the account name specified by Username.
5. Store encrypted password in profile: You may optionally wish to enable this setting so that you will not be asked to reenter the password each time when logging in after Tunnelier has been restarted.
4. In the C2S Forwarding tab in Tunnelier, add a new entry and configure the following settings for this entry. Click also the ‘Help’ link on the C2S Forwarding tab for help with any of these settings.
1. Status: This will be ‘enabled’ by default, leave it that way.
2. Listen interface: The default value is 127.0.0.1. If the client machine is running Windows XP, leave this as it is; you will need to uninstall file and printer sharing on the client machine anyway. If the client machine is running Windows 2000, change this to 127.0.0.2 so that you will not need to uninstall file and printer sharing.
3. List. Port: 139.
4. Destination Host: set this to the interface on which the file sharing server is listening for SMB connections. Setting this to ‘localhost’ or 127.0.0.1 will not work because the file sharing server is usually listening on a specific interface rather than all interfaces, so it will not be possible to go through the loopback connection. To determine the interface where the file sharing server is listening, execute ‘netstat -an’ on the server and examine the output for a line like ‘xxxxxx:139 … LISTENING’. The xxxxxx is the IP address that you need to enter in this field. Normally this will be the IP address associated with the server’s main ethernet adapter.
5. Dest. Port: 139.
5. Click the Login button in Tunnelier and observe the log area for any errors. If the session is established without errors, the SSH setup is running.
6. If you are running Windows XP, you will now need to uninstall (not just disable, but completely uninstall) file and printer sharing on the client machine. This can be done through Network Connections : (each connection) : Properties – select ‘File and Printer Sharing’ in the list box and press the Uninstall button. This needs to be done for each active network connection on the client machine.
7. If you are using earlier versions of Windows (this is confirmed for Windows 2000 but is likely to apply to the 9x/Me series as well), you will not need to uninstall file and printer sharing if you specified 127.0.0.2 as the Tunnelier C2S rule listening interface (above).
8. Once the above steps have been completed, you will be able to connect securely to the shared resources on the server machine using syntax such as \\127.0.0.1\sharename or \\127.0.0.2\sharename, respectively. This will work as long as the Tunnelier SSH connection remains established.
9. You can make sure that your file sharing connections are going through Tunnelier by checking the Tunnelier log area for a message saying ‘Accepted client-to-server connection from … to …:139’ corresponding to each connection attempt you make. Likewise, when your file sharing connection closes, Tunnelier should output a log message stating ‘Closing client-to-server forwarding channel from … to …:139’.
Troubleshooting
If you encounter problems establishing the SSH session, you will receive diagnostic information in the Tunnelier log area, as well as in the log entries recorded by WinSSHD on the server side. Especially in the case of an authentication failure, the WinSSHD log entries will contain important diagnostic information. Inspect the WinSSHD log entries using the Windows Event Viewer on the server side.
Please see our contact and support page for more information and links to documents about how to go about resolving problems with Tunnelier and WinSSHD.
huh.. i am gonna need a new hardisk soon..
just about to test few thing on centos5.. which is equivalent to RHEL5..
but somehow..
no more space left..
have you ever have this kind of display..when running an applet ?
while the code is just like this..
Socket s = null;
try {
s = new Socket(getCodeBase().getHost(),Integer.parseInt(p.getProperty(“image.1.port”)));
// changed the status.. to state that we’re connected?
status.setText(“Connected to:” + getCodeBase().getHost() + “:” + p.getProperty(“image.1.port”));
OutputStream slout = s.getOutputStream();
BufferedWriter bw = new BufferedWriter(
new OutputStreamWriter(slout));
bw.write(“GET ” + imageURL2 + ” HTTP/1.0 \r\n\n”);
status.setText(“Written : ” + imageURL2 + “to socket.”);
//close it
BufferedReader br = new BufferedReader(
new InputStreamReader(s.getInputStream()));
System.out.println(br.readLine());
bw.close();
s.close();
} catch (IOException e)
{
//e.printStacktrace();
}
cd /home ; tar cvf – user | ssh remotemachine ‘cd /destination ; tar xf -‘
it will transfer all file in /home/user to remotemachine:/destination
later on.. you might need to transfer back..
using..
ssh remotemachine ‘cd /destination ; tar cvf – user’ | cd /home/ ; tar xf –
Socket Programming in Java
(Page 1 of 4 )
In a world which is wired, standalone applications are becoming obsolete. The facilitators for the connectivity of applications, at a low level, are sockets. Any language, whether high-level or low-level, must provide APIs to handle sockets if its creators want it to be widely accepted.
Java is no exception. Java facilitates socket programming through its java.net package. And true to its philosophy, it abstracts out most of the low-level “nitty-gritty” associated with sockets and provides a clean object-oriented API to work with.
In this article I will discuss how to use the java.net package to net enable any application (CLI or GUI based) with TCP based sockets. The first section will cover what sockets are and how they have been supported in Java. In the second section, I will enumerate the steps you need to take to use sockets within an application. In the last two sections I will develop a real world application using sockets. That sets the course for this discussion.
Sockets: what are they?
If one looks up the definition, the most common one would be “A socket is one endpoint of a two-way communication link between two programs running on the network.” To put it differently, it is through sockets that applications access the network and transmit data. The types of sockets are as varied as the purposes and platforms of applications. There are three types of sockets:
1. Unix Domain Sockets
2. Internet Domain Sockets
3. NS Domain Sockets
Of these only Internet Domain Sockets are supported across all platforms. So to maintain the cross-platform characteristic intact, Java supports only Internet Domain Sockets. The next question that arises is what are the characteristics of an Internet Domain Socket and what protocols are supported by it? Here are the answers.
Internet Domain Sockets
By definition “An Internet socket (or commonly, a socket or network socket), is a communication end-point unique to a machine communicating on an Internet Protocol-based network, such as the Internet.” All applications communicating through the Internet use a network socket. The feature that distinguishes a network sockets from other sockets is the protocols that it supports. The supported protocols are:
1. TCP
2. UDP
3. Raw IP
The difference between them is based on whether the protocol is connection oriented or not. Here are the details.
TCP is one of the core protocols of the Internet protocol suite. The protocol guarantees reliable and in-order (correct order of packets) delivery of data from sender to receiver. To put it simply, it’s reliable. The second aspect of TCP is that it is connection oriented. That means TCP requires that a connection be made between the sender and receiver before data is sent. The socket associated with TCP is known as the Stream Socket.
UDP, like TCP, is one of the core protocols of the IP suite. However, unlike TCP, it neither guarantees in-order delivery of data nor does it requires a connection to be established for sending the data. To put it simply, UDP is an unreliable and connectionless protocol. Sockets associated with UDP are known as Datagram Sockets.
Raw IP is a non-formatted protocol, unlike TCP and UDP. It works at network and transport layers. A socket associated with Raw IP is known as a Raw Socket. UDP and TCP sockets just receive the payload or the data, whereas Raw Sockets receive the header info of the packet along with the data. The downside of Raw Sockets is that they are tightly coupled with the implementation provided by the underlying host operating system.
Next let’s see how Java places the different types of sockets in its libraries.
Sockets in Java
Like all other functionalities provided by Java, functionalities to work with sockets are also “packaged” as a package and its classes. The following are the package and its main classes that help in accessing sockets:
1. java.net package
2. ServerSocket
3. Socket
Among the above, Java abstracts out most of the low-level aspects of socket programming. Here are the details.
The java.net package contains all the classes required to create network enabled applications. ServerSocket and Socket are also part of this package. Apart from these classes, it also contains classes to connect to the web server, create secured sockets, and so forth.
The ServerSocket class provides server sockets or sockets at server side. Such sockets wait for requests over the network. Once such requests arrive, a server socket performs operations based on the request and may return a result. The ServerSocket class wraps most of the options required to create server-side sockets.
The Socket class provides client-side sockets or simply sockets. They are at the client side connecting to the server, sending the request to the server and accepting the returned result. Just as ServerSocket exposes only the compulsory parameters required to create a server-side socket, similarly, Socket asks the user to provide only those parameters that are most necessary.
That covers sockets and Java. In the next section, I will discuss the steps involved in creating socket-based applications.
…
continue here..
http://www.devarticles.com/c/a/Java/Socket-Programming-in-Java/
hahaha..
khas tuk mat rempit..
o1bakOd2hOs
utk bakal pengantin.. :P
1lOIxCEpKuA
Lagu jawa ?..
wDb05jMfb_M
http://www.dnsstuff.com/tools/aboutyou.ch
http://whatismyip.oceanus.ro/
http://www.whatismyip.org/
haha.. starting today .. i am testing maxis broadband service…in petaling jaya..
wahahha…
HSDPA Wireless Access Terminal..
M | T | W | T | F | S | S |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 |