In article <caocn9rzgalqep3qiqxup-w0ftdwn5datevdoe42q3pta9wq...@mail.gmail.com> 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 <futat...@yf.bsdclub.org>
