« December 2006 | Main | February 2007 »
January 23, 2007
Reusing SSH Authentication with Subversion and CVS
Since OpenSSH 4.0, the ssh client has had the capability of reusing existing open connections, bypassing authentication. I have learned that this feature, called ControlMaster, is a great benefit when connecting to a Subversion or CVS repository on a server that doesn't allow public key authentication. Without this feature, one would need to enter their password for each SVN or CVS operation when connecting to those servers.
There are two things that one must do to make use of ControlMaster with ssh.
1. Add a directive to your ~/.ssh/config file that tells ssh to use an existing ControlMaster socket if it exists and what the filename of that socket is. A simple form is:
ControlPath ~/.ssh/control-%r@%h:%pThis tells ssh to look for a control socket named "control-" followed by the remote user name, remote hostname, and remote port number. If one does not exist, no problem, ssh should behave as it normally did and not attempt to reuse a connection.
It might be a good idea to wrap that directive in a Host directive that tells it to only attempt this for certain hostnames that you specify. You could possibly run into trouble if a program you're using already sets up the ControlMaster and ControlPath for you. This directive may change the ControlPath to something such programs aren't expecting. I've not seen this myself, but I have read reports of people having trouble with a certain GUI Subversion client.
2. Start up an ssh ControlMaster connection to the server that holds your SVN or CVS repository. The simplest method is:
ssh -M hostname(The option "M" puts ssh into "master" mode for sharing connections.)
This will create the control socket at the path specified by the ssh ControlPath configuration directive and prompt you for your password. After authenticating, you will have a regular ssh session. The problems with this is that you would need to keep the session window open or active and if your session has an inactivity timeout, the session could be gone when you need it.
Sometimes a better method is to also tell ssh to run in the background and don't execute any command on the remote host. Like this:
ssh -fNM hostname(The option "f" forces ssh into the background and "N" tells it not to execute a remote command.)
It would be a good idea to assign this "ssh -fNM" command to a shell alias like "ssh-master". With this ssh master client in the background, you will need to keep track of the process yourself. You might be comfortable just using the "ps" command in a shell or maybe a process listing GUI would be helpful to you. It would be nice to have a GUI that could start and monitor these ControlMaster sessions for you, but I don't know of any now.
Lately, since I couldn't find an ssh GUI I like, I've been using a slightly different set of options:
ssh -NMv(The option "v" puts ssh into verbose mode.)
The verbose mode is the opposite of the background mode. ssh will show information about every operation it performs. I run this in a separate terminal window, so I can see that my ssh connection is still working as I'm doing other things. I've found it useful to wrap this command in a small shell script that wraps an infinite loop around ssh, followed by a prompt to press return to reconnect when ssh exits. This helps when my computer loses its connection to the server because I've moved to a different network or if my computer has been sleeping.
Finally, easiest way to try it out is open another window and use a simple ssh command to open a connection to the same hostname that you used earlier:
ssh hostnameYou shouldn't be prompted for any authentication.
The nice thing about this method is that it takes very little configuration to set up, uses a very simple command to start the ControlMaster, and any ssh command after the master one will work the way it should, but without additional authentication.
There is another ControlMaster option called "auto" that could be useful. It will use an existing control socket if it exists, or create a new one and become a ControlMaster. The problem with using that setting is if ssh is being called from an SVN or SSH client, this master session will only be around for as long as the interaction with the repository takes to complete. It would also prompt for a password, which could be a problem if the SVN or SSH client is a GUI.
Other documentation about this feature:
http://www.revsys.com/writings/quicktips/ssh-faster-connections.html
http://www.linux.com/article.pl?sid=06/05/19/145227
Posted by lsloan at 03:42 PM | Comments (0)
January 19, 2007
HTML Playground: Reference By Interactive Example
HTML Playground, html, css reference by example
Posted by lsloan at 08:18 PM | Comments (0)
Creating and Applying Patches
This article, "How to create and use a patch in Linux", explains how to use the diff and patch commands to create and apply patches, respectively. This ability is not limited to Linux. It is available under most brands of Unix (including Mac OS X) and similar Windoze utilities are available, too.
Posted by lsloan at 08:01 AM | Comments (0)
January 12, 2007
Using Two Databases with Hibernate
JavaRanch Big Moose Saloon: how to use 2 database in hibrnates.
Just use two configurations. E.g. :
code:
Properties databaseAProperties = // get properties however you like
Properties databaseBProperties = // get properties however you like
SessionFactory databaseA
= new Configuration().configure("databaseA.cfg.xml")
.setProperties(databaseAProperties)
.buildSessionFactory();
SessionFactory databaseB
= new Configuration().configure("databaseB.cfg.xml")
.setProperties(databaseBProperties)
.buildSessionFactory();
Posted by lsloan at 11:03 AM | Comments (0)
January 11, 2007
Hibernate Configuration "Resources"
I'm thinking of using Hibernate in a Java web application to connect to two different databases at the same time. So I looked up Configuration (Hibernate API Documentation) to find this:
configure(String resource)
Use the mappings and properties specified in the given application resource.
Maybe it's because I haven't been using Java very long and I don't know the jargon and common practices very well, but that doesn't look like I should use it to specify a filename. I thought the resource String was supposed to be a string already in memory that contains the configuration.
So I wasted time trying other methods like configure() that takes a File object (didn't work for me) and both versions of addFile (I found later it reads a mapping, not a config).
I learned that I was naive to believe that the API documentation produced by Javadoc would be complete and illuminating. I finally downloaded the Hibernate documentation and I found the version of configure() that takes a String expects the name of the file containing the configuration in that string, not the configuration itself. So it's exactly what I wanted. It wasn't explained in so many words, though. It was in a code sample, but I was able to figure it out quickly.
What's more, I found that I didn't need to specify the full path to the file, either. As long as the file I named is in the classpath, it will be found. That's a big help.
I'm still disappointed with the Hibernate documentation thus far.
Posted by lsloan at 02:30 PM | Comments (0)
January 05, 2007
Not Quite ssh-askpass in Python
macosxhints.com - Create protected passwordless ssh logins - Part 3 of 3
This is the hint I mentioned with a Python-based ssh-askpass. It's not quite right, though. It could be fixed easily, though.
askpass
Posted by lsloan at 07:49 PM | Comments (0)
A Shell-Based ssh-askpass Using Mac OS X Keychain
From TextMate Blog � Keychain Access From Shell:
"The command to access the keychain is security and it has a manual page. But let me save you some time and give you the gist of it."
I've been using an old, unsupported copy of Bill Bumgarner's nice SSHPassKey to answer ssh askpass requests. It works well most of the time, but occasionally it doesn't work right and it's a bit slow.
With the information from this article about retrieving passwords from the Mac OS X keychain, a simple Python program that uses this method may be faster and easier to maintain.
A comment on that page refers to a hint at macosxhints.com for a Python ssh-askpass program that does this and interprets hex-encoded characters in the passwords. From what I can see of it, though, it's not a true ssh-askpass program. I haven't read the whole three-part hint, but I think it's being used in a special way. It asks the keychain for services named "SSH", but it should actually be asking for the hostname of the remote host.
Posted by lsloan at 07:43 PM | Comments (0)
January 04, 2007
Alternate Subversion for Mac OS X (with Password Caching?)
This fellow at codingmonkeys.de (home of the excellent SubEthaEdit collaborative text editor) maintains a version of Subversion binaries for Mac OS X. His appears to be a newer version than the recommended Mac OS X binaries recommended by the Subversion home page.
What's interesting is that this version may cache passwords. At least, that's what one of his postings for an earlier version says. It stores them in the Mac OS X Keychain facility.
I bet that the passwords it stores are not ssh passwords, though. I will have to try it and find out.
Posted by lsloan at 03:11 PM | Comments (0)
Subversion with SSH
Sporadic Motion � Blog Archive � Getting started with SVN SSH
I would like to use svn (Subversion) via ssh without having to enter my password every time. The information on this page may be helpful eventually, but at this time, I don't see that it offers anything better than public key authentication.
I am just getting started with svn and I want to use a repository on a remote server via ssh. My repository there is stored in an AFS directory. The server I want to use automatically authenticates me to AFS when I enter my Kerberos password.
The free svn book suggests that ssh-agent can be used to store passwords. From what I've seen so far, it doesn't do that.
The problem I'm running into here is that the server that automatically authenticates me to AFS has its sshd configured specifically to disallow public key authentication.
Another server I use does allow public key authentication, but since I don't enter a password as I log in, I don't get authenticated to AFS. And since I already have my ssh keys set up with that server, I don't need ssh-agent in that scenario at all.
So I'm thinking of a couple possible solutions, either of which would require me to run a program on a remote server with each session before I can use my svn repository:
1. Use ssh to connect to the server that don't allow public key authentication and run my own copy of ssh on another port that does allow that authentication method. Then I would configure svn to connect to that port.
2. Use ssh to connect to the server that does allow public key authentication and manually authenticate to AFS. All connections after that should be able to access my svn repository in AFS.
Either way, ssh connection I use would need to remain open while I'm doing any work with svn.
Posted by lsloan at 08:49 AM | Comments (0)