Re: using svn cli with --non-interactive (in scripts) securely,without exposing password
In article nka...@gmail.com writes: > Sorry for message without content, re-sending with content. > > > On Mon, Feb 22, 2021 at 3:25 PM Yasuhito FUTATSUKI > > > > If you want to use ssh key other than default key or alternative tcp port > > > other than 22, you can use them by overriding ssh tunnel setting with > > > SVN_SSH > > > environment variable or config file, etc. (Of course, if you want to use > > > non > > > standard port for ssh connection you also need to change configuration of > > > sshd on server side). > > No. SSh keys without passphrases are much like Post-it notes with > passwords on them, or stored passwords in Subversion. It is ture, but as I wrote in another message, I think there is no safer way, as far as using automation kicked by cron, directly. > Tools that can > write to a source control without anyone unlocking the key are quite > dangerous. It's no need to give write access for the purpose of this thread and threre is a way to give read only permisson, but it is off topic. > It's straightforward to use ssh-agent to unlock and store access to > the key after a server is booted, but requiring a console to set up > *once* and save long-term. The old "keychain" tool works quite well > for this, and can enable ephemereal access to a live ssh-agent as > needed. For automated build tools like Jenkins, they can even store > the private key internally, encrypted with the SSH server's > encryption, and restricted to certain Jenkins "folders" for project > specific access. I use this approach regularly for Jenkins and source > control. Then how do the agent distinguish process kicked by cron and those process created by someone which has a privillage to start cron daemon, or even has a privillage to modify cron jobs? I think giving secrets to some process on system boot without storing file system or non-volatile memory has only advantage against off line attacks. I think it is a balance of confidentiality and availability. Anyways I'm using svn+ssh in my enrionment, but please do risk assessment in your own environment, even though I thought it was needless to say. Cheers, -- Yasuhito FUTATSUKI
Re: using svn cli with --non-interactive (in scripts) securely, without exposing password
Sorry for message without content, re-sending with content. > On Mon, Feb 22, 2021 at 3:25 PM Yasuhito FUTATSUKI > > If you want to use ssh key other than default key or alternative tcp port > > other than 22, you can use them by overriding ssh tunnel setting with > > SVN_SSH > > environment variable or config file, etc. (Of course, if you want to use non > > standard port for ssh connection you also need to change configuration of > > sshd on server side). No. SSh keys without passphrases are much like Post-it notes with passwords on them, or stored passwords in Subversion. Tools that can write to a source control without anyone unlocking the key are quite dangerous. It's straightforward to use ssh-agent to unlock and store access to the key after a server is booted, but requiring a console to set up *once* and save long-term. The old "keychain" tool works quite well for this, and can enable ephemereal access to a live ssh-agent as needed. For automated build tools like Jenkins, they can even store the private key internally, encrypted with the SSH server's encryption, and restricted to certain Jenkins "folders" for project specific access. I use this approach regularly for Jenkins and source control. SSH access is also vulnerable to changing host keys in DHCP based environments. Do look up SSH hostkeys and the keyword "/dev/null" to find many notes about how to disable this, including ones I've been publishing for decades.
Re: using svn cli with --non-interactive (in scripts) securely, without exposing password
On Mon, Feb 22, 2021 at 3:25 PM Yasuhito FUTATSUKI wrote: > > Hello, > > On 2021/02/23 2:40, CoolCold wrote: > > Good day! > > (please CC me, I'm not subscribed to the list) > > > > A bit of context: > > I was using subversion to store my serves' configs versioned for > > almost a decade, with bash wrapping around it. Simplified, it had repo > > per server name, wrapper called by cron to checkout, rsync over, > > commit changes back, sending email on diffs ( > > https://github.com/coolcold/svnbackup ). Had no issue with it, when > > password store was enabled. It's runned under root user and saved > > credentials are not exposed to non-admin users on the system. > > > > Issue: with recent changes hitting packages in distributions ( > > https://marc.info/?l=subversion-commits=154101482302608=2 ), that > > seems to be not possible anymore. > > I did adjust my script to use command line switch --password, but this > > makes it visible for anyone who does simple commands like ps aux. > > I've tried to look around for possible support of environment > > variables / password file support, but couldn't find any except some > > old proposals like > > http://subversion.1072662.n5.nabble.com/Feature-proposal-SVN-USERNAME-and-SVN-PASSWORD-environment-variables-td180031.html > > > > Rebuilding subversion from source is not an option for many reasons. > > > > Seeking for your help on this, what is the proper way of doing this > > with recent versions? > > Thanks in advance. > > For this purpose, I'm just using svn+ssh:// with dedicated user on > server side and public key authentication with empty pass phrase. > > e.g. svn+ssh://svn-ag...@svnhost.example.org/repo/ > > On svnhost.example.org, authorized_key file for user svn-agent could be: > [[[ > # only for svn agent via ssh. all lines shoud be started with following > # command and option specification: > command="/usr/bin/svnserve -t -r /base/path/to/repo > --tunnel-user=root-on-hostA",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty > ssh-ed25519 (public key A) r...@hosta.example.org > command="/usr/bin/svnserve -t -r /base/path/to/repo > --tunnel-user=root-on-hostB",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty > ssh-ed25519 (public key B) r...@hostb.example.org > ... > ]]] > > Cf. > http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks > > If you want to use ssh key other than default key or alternative tcp port > other than 22, you can use them by overriding ssh tunnel setting with SVN_SSH > environment variable or config file, etc. (Of course, if you want to use non > standard port for ssh connection you also need to change configuration of > sshd on server side). > > Cheers, > -- > Yasuhito FUTATSUKI
Re: using svn cli with --non-interactive (in scripts) securely,without exposing password
In article coolthec...@gmail.com writes: > As I see it, at the end of the day, cleartext password / token / > ssh-key would be saved anyway, if you need to have it to work in an > automated way. > Most convenient for me would be having: > a) --pasword-file=... command option > b) SVN_PASSWORD environment variable > > both of them should not be hard to implement and both provide access > to current and/or root user, compared to current implementation, when > running "ps aux" to reveal --password=... param executed by any user > (this param could be at least googled fast and majority of people > won't go deep into crafting simple auth file themselves). Environment variables passed by a parent can be seen by others, too. Some implementation of ps(1) utility has an option to display it. Also, procfs on Linux provide /proc/$pid/environ. I don't think there is a safe way that a process kicked by cron can get credentials but other processes which have same privilage can't get them. Cheers, -- Yasuhito FUTATSUKI
Re: using svn cli with --non-interactive (in scripts) securely, without exposing password
Hello! On Tue, Feb 23, 2021 at 2:37 AM Nathan Hartman wrote: > > On Mon, Feb 22, 2021 at 1:17 PM CoolCold wrote: > > > > Good day! > > (please CC me, I'm not subscribed to the list) > > > > A bit of context: > > I was using subversion to store my serves' configs versioned for > > almost a decade, with bash wrapping around it. Simplified, it had repo > > per server name, wrapper called by cron to checkout, rsync over, > > commit changes back, sending email on diffs ( > > https://github.com/coolcold/svnbackup ). Had no issue with it, when > > password store was enabled. It's runned under root user and saved > > credentials are not exposed to non-admin users on the system. > > > > Issue: with recent changes hitting packages in distributions ( > > https://marc.info/?l=subversion-commits=154101482302608=2 ), that > > seems to be not possible anymore. > > I did adjust my script to use command line switch --password, but this > > makes it visible for anyone who does simple commands like ps aux. > > I've tried to look around for possible support of environment > > variables / password file support, but couldn't find any except some > > old proposals like > > http://subversion.1072662.n5.nabble.com/Feature-proposal-SVN-USERNAME-and-SVN-PASSWORD-environment-variables-td180031.html > > > > Rebuilding subversion from source is not an option for many reasons. > > > > Seeking for your help on this, what is the proper way of doing this > > with recent versions? > > Thanks in advance. > > Hello, > > Recent versions (1.12.x and newer [1]) by default don't _save_ > passwords to disk in plaintext (unless configured to do so at > build-time). > > However, Subversion will _use_ the password, if it is already stored > on disk. > > So, as a workaround, you could use some out-of-band method to save the > password to disk either by using an older SVN client or by generating > a file with the right bits in it: That's good news for me, will poke around. > > In a recent discussion on our dev mailing list, there is an example > shell script (for zsh) that saves a password file. See [2] and note > that there were a few corrections to the script so be sure to use the > latest version in that mail list thread. > > [1] > https://subversion.apache.org/docs/release-notes/1.12.html#client-server-improvements Thanks for the links with discussion and proposed solution, really helpful. Also it expresses the same feeling and reaction I have, but stated in much better English. > > [2] > https://lists.apache.org/thread.html/r0eef40236aeddd1db18bc7882454dd3b18bcd721d8fd8c9e21aca52a%40%3Cdev.subversion.apache.org%3E > > I hope the above is helpful; feel free to ask as many questions as you > need to, or propose improvements to the above-mentioned script or > Subversion itself. We have gotten quite a few questions about this and > it has been frustrating for anyone who uses svn as part of cron jobs > in non-X environments, where the available encrypted password stores, > Kwallet and Gnome-keyring, aren't much help, and GPG-Agent doesn't > persist the passwords indefinitely. > We would be really grateful if > someone could propose a solution that works well in these scenarios > while alleviating people's concerns about storing passwords on disk in > plaintext. As I see it, at the end of the day, cleartext password / token / ssh-key would be saved anyway, if you need to have it to work in an automated way. Most convenient for me would be having: a) --pasword-file=... command option b) SVN_PASSWORD environment variable both of them should not be hard to implement and both provide access to current and/or root user, compared to current implementation, when running "ps aux" to reveal --password=... param executed by any user (this param could be at least googled fast and majority of people won't go deep into crafting simple auth file themselves). Live examples of cleartext passwords/tokens are numerous - SAMBA mount passwords, AWS access tokens, deployment ssh keys and so on, which are stored in cleartext anyway - I'd say industry made it's choice already. For advanced feature, it could be having something like SVN_ASK_PASS_PROGRAM helper support, it can be sophisticated enough to connect to some URL and get password from there, without storing it on any local disk, but that's much harder to implement and setup by end user. If such helpers would be bundled with subversion (like email notification scripts in Perl, for example), there is a non-zero chance someone will use it. > > Cheers, > Nathan Thanks again for your reply, Nathan! -- Best regards, [COOLCOLD-RIPN]
Re: using svn cli with --non-interactive (in scripts) securely, without exposing password
Hello, On Tue, Feb 23, 2021 at 3:23 AM Yasuhito FUTATSUKI wrote: > > Hello, > > On 2021/02/23 2:40, CoolCold wrote: > > Good day! > > (please CC me, I'm not subscribed to the list) > > > > A bit of context: > > I was using subversion to store my serves' configs versioned for > > almost a decade, with bash wrapping around it. Simplified, it had repo > > per server name, wrapper called by cron to checkout, rsync over, > > commit changes back, sending email on diffs ( > > https://github.com/coolcold/svnbackup ). Had no issue with it, when > > password store was enabled. It's runned under root user and saved > > credentials are not exposed to non-admin users on the system. > > > > Issue: with recent changes hitting packages in distributions ( > > https://marc.info/?l=subversion-commits=154101482302608=2 ), that > > seems to be not possible anymore. > > I did adjust my script to use command line switch --password, but this > > makes it visible for anyone who does simple commands like ps aux. > > I've tried to look around for possible support of environment > > variables / password file support, but couldn't find any except some > > old proposals like > > http://subversion.1072662.n5.nabble.com/Feature-proposal-SVN-USERNAME-and-SVN-PASSWORD-environment-variables-td180031.html > > > > Rebuilding subversion from source is not an option for many reasons. > > > > Seeking for your help on this, what is the proper way of doing this > > with recent versions? > > Thanks in advance. > > For this purpose, I'm just using svn+ssh:// with dedicated user on > server side and public key authentication with empty pass phrase. > > e.g. svn+ssh://svn-ag...@svnhost.example.org/repo/ > > On svnhost.example.org, authorized_key file for user svn-agent could be: > [[[ > # only for svn agent via ssh. all lines shoud be started with following > # command and option specification: > command="/usr/bin/svnserve -t -r /base/path/to/repo > --tunnel-user=root-on-hostA",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty > ssh-ed25519 (public key A) r...@hosta.example.org > command="/usr/bin/svnserve -t -r /base/path/to/repo > --tunnel-user=root-on-hostB",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty > ssh-ed25519 (public key B) r...@hostb.example.org > ... > ]]] Thanks for sharing this - I still see such a way as a workaround, but as a reasonable workaround. One may want to prefer it due to data transfer encryption it provides. >From the other side, it's a trade of "cleartext" password vs "unprotected ssh key" (while key can be IP bound in .ssh/authorized_keys thus making it a bit better protected in case of leakage). > > Cf. > http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks > > If you want to use ssh key other than default key or alternative tcp port > other than 22, you can use them by overriding ssh tunnel setting with SVN_SSH > environment variable or config file, etc. (Of course, if you want to use non > standard port for ssh connection you also need to change configuration of > sshd on server side). > > Cheers, > -- > Yasuhito FUTATSUKI -- Best regards, [COOLCOLD-RIPN]
Re: using svn cli with --non-interactive (in scripts) securely, without exposing password
Hello, On 2021/02/23 2:40, CoolCold wrote: > Good day! > (please CC me, I'm not subscribed to the list) > > A bit of context: > I was using subversion to store my serves' configs versioned for > almost a decade, with bash wrapping around it. Simplified, it had repo > per server name, wrapper called by cron to checkout, rsync over, > commit changes back, sending email on diffs ( > https://github.com/coolcold/svnbackup ). Had no issue with it, when > password store was enabled. It's runned under root user and saved > credentials are not exposed to non-admin users on the system. > > Issue: with recent changes hitting packages in distributions ( > https://marc.info/?l=subversion-commits=154101482302608=2 ), that > seems to be not possible anymore. > I did adjust my script to use command line switch --password, but this > makes it visible for anyone who does simple commands like ps aux. > I've tried to look around for possible support of environment > variables / password file support, but couldn't find any except some > old proposals like > http://subversion.1072662.n5.nabble.com/Feature-proposal-SVN-USERNAME-and-SVN-PASSWORD-environment-variables-td180031.html > > Rebuilding subversion from source is not an option for many reasons. > > Seeking for your help on this, what is the proper way of doing this > with recent versions? > Thanks in advance. For this purpose, I'm just using svn+ssh:// with dedicated user on server side and public key authentication with empty pass phrase. e.g. svn+ssh://svn-ag...@svnhost.example.org/repo/ On svnhost.example.org, authorized_key file for user svn-agent could be: [[[ # only for svn agent via ssh. all lines shoud be started with following # command and option specification: command="/usr/bin/svnserve -t -r /base/path/to/repo --tunnel-user=root-on-hostA",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-ed25519 (public key A) r...@hosta.example.org command="/usr/bin/svnserve -t -r /base/path/to/repo --tunnel-user=root-on-hostB",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-ed25519 (public key B) r...@hostb.example.org ... ]]] Cf. http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks If you want to use ssh key other than default key or alternative tcp port other than 22, you can use them by overriding ssh tunnel setting with SVN_SSH environment variable or config file, etc. (Of course, if you want to use non standard port for ssh connection you also need to change configuration of sshd on server side). Cheers, -- Yasuhito FUTATSUKI
Re: using svn cli with --non-interactive (in scripts) securely, without exposing password
On Mon, Feb 22, 2021 at 1:17 PM CoolCold wrote: > > Good day! > (please CC me, I'm not subscribed to the list) > > A bit of context: > I was using subversion to store my serves' configs versioned for > almost a decade, with bash wrapping around it. Simplified, it had repo > per server name, wrapper called by cron to checkout, rsync over, > commit changes back, sending email on diffs ( > https://github.com/coolcold/svnbackup ). Had no issue with it, when > password store was enabled. It's runned under root user and saved > credentials are not exposed to non-admin users on the system. > > Issue: with recent changes hitting packages in distributions ( > https://marc.info/?l=subversion-commits=154101482302608=2 ), that > seems to be not possible anymore. > I did adjust my script to use command line switch --password, but this > makes it visible for anyone who does simple commands like ps aux. > I've tried to look around for possible support of environment > variables / password file support, but couldn't find any except some > old proposals like > http://subversion.1072662.n5.nabble.com/Feature-proposal-SVN-USERNAME-and-SVN-PASSWORD-environment-variables-td180031.html > > Rebuilding subversion from source is not an option for many reasons. > > Seeking for your help on this, what is the proper way of doing this > with recent versions? > Thanks in advance. Hello, Recent versions (1.12.x and newer [1]) by default don't _save_ passwords to disk in plaintext (unless configured to do so at build-time). However, Subversion will _use_ the password, if it is already stored on disk. So, as a workaround, you could use some out-of-band method to save the password to disk either by using an older SVN client or by generating a file with the right bits in it: In a recent discussion on our dev mailing list, there is an example shell script (for zsh) that saves a password file. See [2] and note that there were a few corrections to the script so be sure to use the latest version in that mail list thread. [1] https://subversion.apache.org/docs/release-notes/1.12.html#client-server-improvements [2] https://lists.apache.org/thread.html/r0eef40236aeddd1db18bc7882454dd3b18bcd721d8fd8c9e21aca52a%40%3Cdev.subversion.apache.org%3E I hope the above is helpful; feel free to ask as many questions as you need to, or propose improvements to the above-mentioned script or Subversion itself. We have gotten quite a few questions about this and it has been frustrating for anyone who uses svn as part of cron jobs in non-X environments, where the available encrypted password stores, Kwallet and Gnome-keyring, aren't much help, and GPG-Agent doesn't persist the passwords indefinitely. We would be really grateful if someone could propose a solution that works well in these scenarios while alleviating people's concerns about storing passwords on disk in plaintext. Cheers, Nathan
using svn cli with --non-interactive (in scripts) securely, without exposing password
Good day! (please CC me, I'm not subscribed to the list) A bit of context: I was using subversion to store my serves' configs versioned for almost a decade, with bash wrapping around it. Simplified, it had repo per server name, wrapper called by cron to checkout, rsync over, commit changes back, sending email on diffs ( https://github.com/coolcold/svnbackup ). Had no issue with it, when password store was enabled. It's runned under root user and saved credentials are not exposed to non-admin users on the system. Issue: with recent changes hitting packages in distributions ( https://marc.info/?l=subversion-commits=154101482302608=2 ), that seems to be not possible anymore. I did adjust my script to use command line switch --password, but this makes it visible for anyone who does simple commands like ps aux. I've tried to look around for possible support of environment variables / password file support, but couldn't find any except some old proposals like http://subversion.1072662.n5.nabble.com/Feature-proposal-SVN-USERNAME-and-SVN-PASSWORD-environment-variables-td180031.html Rebuilding subversion from source is not an option for many reasons. Seeking for your help on this, what is the proper way of doing this with recent versions? Thanks in advance.
