On Thu, Jul 13, 2023 at 1:49 PM Daniel Sahlberg <daniel.l.sahlb...@gmail.com> wrote: > > Den tors 13 juli 2023 kl 19:08 skrev David Aldrich > <david.aldr...@emea.nec.com>: >> >> Hi Doug >> >> Thanks for your reply. >> >> > Gnome keyring is the normal answer, yes. Once setup it's pretty stable. >> >> The issue for us is that I believe Gnome keyring requires a GUI desktop. We >> want something that works in a terminal ssh session (no desktop). Do you >> know of a way around this? >> >> Would svn+ssh actually avoid password authentication in this scenario? >> Unfortunately, it’s not easy to understand how to go about it. > > > svn+ssh can be made to work this way if you setup public key authentication. > See for example https://www.ssh.com/academy/ssh/public-key-authentication > > The first step is probably to make sure you can access the server via SSH > using your public/private key. Next you must make sure that your user has > write access to the repository. It is possible to configure the server to > only allow SVN access (no shell access) if that is desired. > > The Subversion book has a lot of useful information, for example: > https://svnbook.red-bean.com/en/1.7/svn.serverconfig.choosing.html#svn.serverconfig.choosing.svn-ssh > https://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshauth > > Of course, if you protect your private key with a passphrase, you will have > to enter that passphrase every time you access the server, basically > substituting one password for another. You can store your private key without > a passphrase but it is up to you to decide if that is acceptable from a > security perspective. > > If you allow storing the private key without a passphrase (=> basically > letting anyone with enough authority on the computer to access the home > directory also access the Subversion server) you could also consider storing > the Subversion password in plain text. For more information, see the > following FAQ item on our website: > https://subversion.apache.org/faq.html#plaintext-passwords > > Kind regards, > Daniel Sahlberg
(Looks like Daniel already touched on some of these points while I was writing the following, but maybe there's still something helpful here...) If I understand correctly, the issue you are encountering is as follows: The Subversion working copy, as well as the Subversion command line client, are on a remote machine running some Unix(like) OS (Linux, BSD, etc). You are accessing that machine by a terminal-based SSH session. While working with the Subversion client, any operation that requires a password (e.g., 'svn commit') pops up a GUI password dialog on that *remote* machine, not the machine you're sitting in front of. And that remote machine might be in another country. See further below for workarounds, but first... One solution that should work, but another user and I both tried and were not successful, is to use GPG Agent instead of KDE's and GNOME's keychains. With GPG Agent, it should be possible to either (1) get a text-based password prompt that works over SSH, or (2) using a different module, to automatically load a password from some encrypted store and cache it in memory so that you aren't prompted at all. Maybe you can make one of these scenarios work and, if so, any pointers would be greatly appreciated. The following archived email, part of a larger discussion about the very issue of SVN client use through a SSH session, may be of interest: https://lists.apache.org/thread/lfz4dzy0q8q8jdcd04wv4qzjvbp2ytfk Now, the workarounds. Neither of these are optimal, but they are known to work. Workaround 1: In addition to SSH, also have a VNC (or similar GUI access) session to the remote machine, so that you can access the GUI password dialog when it pops up. To reduce the number of times that happens, I think there is a way to configure the GNOME keyring on that remote machine to cache passwords in memory for a longer period of time; I don't use GNOME so I can't give a step-by-step for that, unfortunately. Workaround 2: If Workaround 1 is too annoying and if the risk of Workaround 2 is acceptable, Subversion supports a plaintext password cache. If your Subversion client is version 1.12.x through 1.14.x, it may or may not be able to *store* passwords in the plaintext cache, depending on how the Subversion client was compiled; however, it will use such cached passwords if already stored. There is a Python script that can store a password in that cache. You could run that once and then not be bothered by password prompts anymore (as long as the password continues to be accepted by the Subversion server). Note again that in this scenario, the password would be cached on disk in plaintext, which may or may not be acceptable to you in your use case. If you're interested in Workaround 2, the following section of the Subversion FAQ discusses how passwords are cached (encrypted or plaintext) and also provides the link to the aforementioned Python script in case you need it: https://subversion.apache.org/faq.html#plaintext-passwords Note that there is a "TODO: Discuss GPG-Agent" there. That's there because, as I said above, I wasn't successful with that. :-/ Hope this helps, Nathan
