A Free Trial That Lets You Build Big!
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
To put it simply, the svn + SSH (SVN over SSH) protocol works by establishing an SSH connection between the svn client and the server, and then pushing commands and transmitting data through the SSH connection, to achieve more secure SVN communication through SSH. Using SVN + SSH to access repository is the biggest difference from common HTTP or HTTPS methods, or the only difference is to log on to the remote host through SSH Security Authentication To establish an SSH connection, if this step is completed, the rest is the pure SVN operation. Before getting started, install the following tools discussed and used in this article:
Putty: http://www.chiark.greenend.org.uk /~ Sgtatham/Putty/download.html
Subclipse: http://subclipse.tigris.org/servlets/ProjectProcess? Pageid = p4wyua
Original article link: http://blog.csdn.net/bluishglc/article/details/8705864 reprint please indicate the source!
I. SVN + SSH: // address
When we try to detect a project using the svn + SSH protocol, in addition to the necessary account password (of course, under normal circumstances, you should also have a key and key phrase passphrase, we will discuss the key later.) The only thing we get is a repository address starting with SVN + SSH. Theoretically, you can use this address and the password to access the remote host's repository. Let's take a look at what the svn + SSH: // format address tells us (SVN client? The following is a typical project address from SourceForge:
This address is the standard SVN address format of the SourceForge project. youraccount represents your sourcegorge account (the account is not required. You can tell your login account in other ways when connecting to the SSH host, for example, if you use Putty to save the session, this example will be demonstrated in later experiment 3), yourproject represents your project. If we interpret this address from the perspective of SSH, this address tells SSH two important information about the client: 1. SSH remote host address: svn.code.sf.net, 2. log on to the SSH remote host account youraccount. In fact, we can log on to svn.code.sf.net based on the two information and the account password you have mastered. A simple verification method is to connect svn.code.sf.net using putty and enter your account password to log on, then you will get the following message:
"Welcome to * .svntest.sourceforge.net" indicates that you have successfully logged on, but the SSH host does not allocate a terminal for you and closes the connection directly. However, this is not important, the key is that we have confirmed that the host address and account provided in the address can establish an SSH connection.
Ii. How does tortoisesvn automatically log on to the SSH remote host?
After confirming that we can establish an SSH connection, we can directly use tortoisesvn to access this address, but you will find that, tortoisesvn constantly requires you to enter the account password (this is demonstrated in "Experiment 1" below). If you insist on entering the password every time, you can finally obtain the complete repository directory structure, this indicates that using tortoise alone can directly access the address in SVN + SSH: // youraccount @ remoteserver/xxxx format, but the only trouble is that you need to enter the password without interruption. (In fact, this is because tortoiseplink is using password authentication to log on. For security reasons, the password will never be cached, so it must be entered every time! We will explain this process later)
Now let's think about the implementation details behind the above process: tortoisesvn knows the remote host address and account by giving the "SVN + SSH: //" address, how does tortoisesvn automatically log on to the SSH remote host? Does tortoisesvn also have built-in SSH client tools like putty to establish SSH connections? The answer should be yes, but we didn't see Tortoise provide a configuration interface like putty in the use process to allow users to configure host addresses and accounts, instead, an SSH connection is automatically established from the address. That is to say, tortoisesvn's SSH connection tool is not a Manual interactive connection tool like putty, it should be a command line tool that can directly call and execute.TortoiseplinkIt is located in the bin subdirectory under the tortoisesvn installation directory. Under SVN + SSH, all requests sent by tortoisesvn to the remote host are first transmitted after an SSH connection channel is established through tortoiseplink. So what kind of tool is tortoiseplink? In fact, it is the SSH Command Line Connection Tool plink provided by putty. tortoiseplink may provide a simple package for plink Based on tortoise's needs, but it is essentially plink, the parameters and usage of tortoiseplink are the same as those of plink, so our problem is: what is plink? How does it work?
Iii. plink: key role behind the scenes
Plink is an SSH command line connection tool. Simply put, using a plink command, we can directly push commands to the remote host through SSH for execution or data transmission. For detailed introduction and use of plink can refer to putty official User Manual: http://the.earth.li /~ Sgtatham/Putty/0.58/htmldoc/chapter7.html. Here we will take a brief look at the plink command line format to understand what it is used.
Plink [Options] [user @] host [command]
For example, assume that there is a remote SSH host 192.168.1.101 with the root account and password 1234. If we want to log on to this host and check the structure under the root directory, we can use the following plink command:
Plink-PW 1234 firstname.lastname@example.org ls/
Similarly, we used Putty to access svn.code.sf.net from the beginning. Now we use plink to connect and push a ls/command and enter:
Plink-PW yourpassword email@example.com ls/
We will get the following response:
Similarly, we get the "Welcome to * .svntest.sourceforge.net" prompt, indicating that we have successfully logged on. However, we are restricted by SourceForge and cannot execute any command. Therefore, we can see that:The main purpose of plink is to allow scripts or some automated processing to connect to the remote SSH host through command lines in non-interactive mode to execute commands. Obviously, under the svn + SSH protocol, SVN client tools need such command line tools to establish SSH connections for SVN operations!This is why tortoisesvn requires tortoiseplink.
Here, the answer to the question "how tortoisesvn automatically logs on to an SSH remote host" is clear: all tortoisesvn communicates with the remote host under SVN + SSH protocol, all are connected to the remote host through SSH established by tortoiseplink!
4. "secret" between putty and plink: Sharing putty session
After learning about plink, compare putty. The relationship between them is similar to that between the database client and the database command line tool. If Putty is a manual configuration (such as remote host address and user name) "clients" that can be connected to remote databases for management (such as SQL Server Management studio of SQL Server or heidisql of MySQL ), plink is a "command line tool" that can be directly connected to a remote database for SQL Execution (for example, SQL server's osql.exew.mysql's mysql.exe ).
However, the relationship between putty and plink is more "closer" than we imagined. There is a very important "Bond" between them. This "Bond" is: plink can directly obtain the session saved in putty and use the session configuration to connect to the remote host. This plink document provides special instructions:
If you have already set up a putty saved session, then instead of supplying a host name, you can give the saved session name. this allows you to use public-key authentication, specify a user name, and use most of the other features of putty.
Yes, let plink use the session saved in Putty to reuse the session configuration. More importantly, Putty session can specify the user name, use the key to log on, and other features, plink uses putty sessions to simplify the command line and implement more configuration with putty sessions.
In fact, Putty will save all session information to the Registry (location: HKEY_CURRENT_USER \ Software \ simontatham), all tools in putty (such as pageant) if necessary, you can obtain the information about these sessions, and even third-party tools can read the information from the registry. Yes, you may have guessed it,Tortoiseplink can also use these sessions! This is the key for tortoisesvn to log on to the remote host using key authentication! Because tortoisesvn does not provide the import key function,TortoiseplinkNo, but putty does. You can use the session configured by putty.
5. Ssh Security Authentication
As mentioned above, when using tortoisesvn to directly access the repository address starting with SVN + SSH: //, a password is always required. The reason is simple. tortoisesvn does not establish an online persistent connection with the SSH remote host, when there is a request, a SSH connection is established through tortoiseplink to pass the request and response, and then disconnect the SSH connection. Tortoisesvn needs to transmit data multiple times to list the repository directory structure. Naturally, a password is required for each request to establish a connection. Is there any trouble with secure identity authentication? Of course, this is to use the key for security authentication. SSH supports two security authentication methods:
1. Password-based security authentication
It is the account + password authentication method, which is the most common and common security authentication method. We have previously used this authentication method to log on.
2. 'key-based 'Security Authentication
Use the key generation tool (ssh-keygen for OpenSSH in Linux and puttygen for putty in Windows) to use a public key and a private key. This is a key pair, the Public Key is placed at the location specified by SSH on the server, and the private key is properly saved by the user. Generally, when a private key is generated, a passphrase is set for it, when the client uses SSH to connect to the server, the private key file and password phrase must be used for security authentication. According to the security authentication type, this is a two-factor authentication method, which is also a very common and more secure authentication method. For example, the key is equivalent to your bank card, a physical credential, and a password phrase is equivalent to your bank card password. The role of a cryptographic phrase is to make the key usage more secure. Suppose that if your private key is obtained by another person who knows your account name and remote host address, then he can use this key to directly connect to the remote host, if you set a password phrase, the key cannot be used even if it is obtained by others. The process of using SSH-keygen and puttygen to generate public and private key pairs is very simple and I will not repeat it here. Please refer to "Key Generation: putty" and "key generation: openSSH.
Go back to the question at the beginning of this section. If you do not use the password, you do not need to enter the password again and again if you do not use the key authentication (refer to experiment 4 below )! If you have set a password phrase for your key, you are not required to enter the password for each access (refer to Experiment 5 below). The solution is to open pageant, add your private key and cache the password phrase, which is safe and does not require repeated password or password phrase (refer to Experiment 5 below). This is the most common configuration method.
6. A series of Verification experiments
After learning how tortoisesvn works when accessing the SSH + SVN protocol, as well as plink, putty, and key-based authentication, We will combine them to perform a series of interesting Verification experiments, through experiments, I can clearly understand how these tools actually work. Please note: Experiment 4, 5, 6 need to generate their own public key and private key, generation method reference http://sourceforge.net/apps/trac/sourceforge/wiki/SSH%20keys article "Key Generation: putty" and "key generation: openSSH ". At the same time, you also need to upload the public key to the SourceForge server. The page for managing the SourceForge key is http://sourceforge.net/account/services. you can find the upload page here. After a long data transfer, it takes up to 10 minutes for the new key to take effect.
Clear all sessions saved in putty and disable pageant. Use tortoise to directly access SVN + SSH: // firstname.lastname@example.org/P/yourproject/code /,
Symptom: it can be accessed, but the SourceForge account and password need to be continuously entered.
Conclusion: when each request occurs, tortoise (specifically, tortiseplink) uses the account youraccount to connect to the remote SSH host svn.code.sf.net first, because there is no other place to save the password or use the key, therefore, you must enter a password for each connection.
Clear all sessions saved in putty and disable pageant. Remove the account from the original address and use tortoise to access SVN + SSH: // svn.code.sf.net/p/yourproject/code /,
Conclusion: The login account is not specified in the address, and there is no corresponding putty session. tortoise does not know which account to use for logon, so the connection fails.
Clear all sessions saved in putty, and create a session named svn.code.sf.net with the host address svn.code.sf.net. In particular, on the connection-> data page, enter your account youraccount in the auto-login username input box, save the session, disable pageant, and remove the account from the original address, use tortoise to access SVN + SSH: // svn.code.sf.net/p/yourproject/code /,
Symptom: it can be accessed, but the SourceForge account and password need to be continuously entered.
Conclusion: although no Logon account is specified in the address, tortoise finds the corresponding putty session. Since the account is set in the session, tortoise uses this account to log on. Of course, the password cannot be saved. Therefore, you must enter the password for each request.
Experiment 4:(Note: passphrase is not required for the key imported in Experiment 4 !)
Clear all sessions saved in putty, and create a session named svn.code.sf.net with the host address svn.code.sf.net. In particular, generate a pair of public and private key pairs (private keys without passphrase ), upload the public key to SourceForge, and enter your account youraccount in the input box of auto-login username on the connection-> data page of the local putty, enter your private key location in the private key file for authentication input box on the connection-> ssh-> auth page, save the session, disable pageant, and remove the account from the original address, use tortoise to access SVN + SSH: // svn.code.sf.net/p/yourproject/code /,
Symptom: it can be accessed without entering the SourceForge account password.
Conclusion: tortoise obtains the account and key from the corresponding putty session, so tortoise uses this account and key for Logon. Because the key is specified, SSH uses the key for verification, so no password is required!
Lab 5:(Note: The key imported in Experiment 5 is passphrase !)
Clear all sessions saved in putty, and create a session named svn.code.sf.net with the host address svn.code.sf.net. In particular, generate a pair of public and private key pairs (the private key includes passphrase ), upload the public key to SourceForge, and enter your account youraccount in the input box of auto-login username on the connection-> data page of the local putty, enter your private key location in the private key file for authentication input box on the connection-> ssh-> auth page, save the session, disable pageant, and remove the account from the original address, use tortoise to access SVN + SSH: // svn.code.sf.net/p/yourproject/code /,
Symptom: it can be accessed without entering the account and password, but passphrase needs to be entered continuously.
Conclusion: tortoise obtains the account and key from the corresponding putty session, so tortoise uses this account and key for Logon. Because the key is specified, SSH uses the key for verification, so no password is required! However, because passphrase is set for the key, it is required for each request.
Keep all settings of Experiment 5, open the pageant tool, and import the private key used in Experiment 5. A password phrase is required during import. Use tortoise again to access SVN + SSH: // svn.code.sf.net/p/yourproject/code /,
Symptom: it can be accessed without entering the account password or passphrase.
Conclusion: tortoise obtains the account and key from the corresponding putty session, so tortoise uses this account and key for Logon. Because the key is specified, SSH uses the key for verification, so no password is required! Because the key and passphrase are added to pageant, in other words, the Authentication Proxy uses pageant to authenticate the key and passphrase. Therefore, the proxy is used to implement pairing authentication between the key and passphrase in each request, therefore, passphrase is no longer required.
7. On the right track, SVN + SSH conventional configuration and Connection Methods (Key Authentication + pageant cache password phrase)
In fact, all of this has been done. In Windows, the conventional configuration and connection mode of SVN + SSH is configured through putty and SVN + SSH: // set the account name and key for the session with the same name as the host name specified in the address, and then open the pageant cache password phrase,For details, refer to Experiment 6.You can.
8. Configure subclipse to access the repository of SVN + SSH protocol
If the configuration of tortoisesvn is successful, the configuration of subclipse is very simple, because subclipse also supports toitoiseplink, as long as we tell subclipse toitoiseplink location, the specific method is: we have configured a system environment variable named svn_ssh with the value of tortoiseplink, for example, c: \ Program Files \ tortoisesvn \ bin \ tortoiseplink.exe, note that the path separator is \\. configure the subclipse plug-in to use javahl, and restart eclipse.
9. configuration in the agent environment
Finally, if your work network uses proxy to access the Internet, you need to create a putty saved session, set the address, port, and type of the proxy server in the connectiong-> proxy item. From the PROXY command input box on this page, we can see that putty uses connect to implement the SSH proxy. At the same time, you also need to set a proxy in tortotise. For proxy settings for subclipse, see this article http://blog.csdn.net/bluishglc/article/details/8658508
Start building with 50+ products and up to 12 months usage for Elastic Compute Service