Use of ssh for authentication?

[David Aldrich]

Hi

 

We currently have around 100 svn users, all of whom are authenticated by password.

 

Password authentication is fine when using a GUI client, but at the command line it becomes tedious. I have tried using Gnome keyring but it seems hard to configure.

 

What is a recommended solution for this problem?

 

Should we use ssh authentication?  Bearing in mind that we would only do so for a subset of users.

 

Best regards

David

 

---

David Aldrich | Consultant Engineer | NEC Telecom Modus Ltd | Olympus House, Cleeve Road, Leatherhead, Surrey, KT22 7SA, GB | t: +44 (0) 1372 381857 | m: | w: www.nec.com

This email (including any attached files) is private and confidential and the exclusive property of NEC Telecom MODUS Ltd. This message is addressed exclusively to its recipient. If you have received this message by mistake, please notify the sender immediately and proceed to delete the message. Unless you have express permission to do so, please do not distribute or copy this email. Except as otherwise stated, the sender does not intend to create a legal relationship and this email shall not constitute an offer or acceptance which could give rise to a contract. View our privacy policy here : https://uk.nec.com/en_GB/emea/privacy/index.html | Registered Office: Olympus House, Business Park 5, Cleeve Road, Leatherhead, Surrey KT22 7SA | Registered in England 3493954 |

[Nico Kadel-Garcia]

On Mon, Jul 10, 2023 at 7:41 AM David Aldrich
<David....@emea.nec.com> wrote:
>
> Hi
>
>
>
> We currently have around 100 svn users, all of whom are authenticated by password.
>
>
>
> Password authentication is fine when using a GUI client, but at the command line it becomes tedious. I have tried using Gnome keyring but it seems hard to configure.

What you're encountering is a client workflow issue. And yeah, svn+ssh
based access is one way to deal.

[Doug Robinson]

David:

On Mon, Jul 10, 2023 at 7:41 AM David Aldrich <David....@emea.nec.com> wrote:

We currently have around 100 svn users, all of whom are authenticated by password.

 

Password authentication is fine when using a GUI client, but at the command line it becomes tedious. I have tried using Gnome keyring but it seems hard to configure.

 

What is a recommended solution for this problem?

Gnome keyring is the normal answer, yes.  Once setup it's pretty stable.

 

Should we use ssh authentication?  Bearing in mind that we would only do so for a subset of users.

Definitely something to consider.  The one "downside" is that the "svnserve" process is short-lived (just for the single command) so it is not capable of having long-term caching the way that Apache does.  The upside is that the svnserve protocol is much more efficient than WEBDAV.  So whether you will see a positive or negative performance impact really does come down to "it depends" on your specific use case.  If the server has sufficient resources and/or the history/checkout/repos are small enough then you likely won't see any difference at all.

Cheers.

Doug

--

DOUGLAS B ROBINSON SENIOR PRODUCT MANAGER

T +1 925 396 1125

E doug.r...@wandisco.com

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED

If this message was misdirected, WANdisco, plc. and its subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this email or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this email message are the author's own and may not reflect the views and opinions of WANdisco, unless the author is authorized by WANdisco to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by WANdisco. Although WANdisco operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.

[David Aldrich]

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.

 

BR

David

[Daniel Sahlberg]

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

[Nathan Hartman]

(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