Correct, default SSH port is not open on the corporate firewall. I am sure
there are workarounds, however having contractual obligations not sure I should
try hard to be unorthodox.
SSH + SVN is my favourite and will stay with it as the primary access method.
If I could top it with HTTP access
Config:
OS: Windows 2012 Server 64bit
1TB SSD
8GiB RAM
Software version4.0.2-3732.117
Subversion version 1.8.3-3732.117
Running since
Gatting Apache to run suid processes and spawn mod_dav_svn processes
has never worked for me, but it's been a long time since I tried it.
It's also unnecessary in most setups: if the svn+ssh is owned by a
single designated user, such as an svn user, with SSH heys stored
for to apply the
sbre...@hotmail.com wrote on Mon, Nov 25, 2013 at 10:24:16 +:
Correct, default SSH port is not open on the corporate firewall. I am
sure there are workarounds, however having contractual obligations not
sure I should try hard to be unorthodox.
I still suggest that you try to run sshd. If
If you go to alternative SSH port, which is not that unusualy, write
and show them the restricted sshd_config to restrict access to only
that specified service for only that specified user. No password
logins, no normal shells, use the authorized_keys ForceCommand access
only for that alternative
Hi,
After upgrading the version of our svn server from 1.7 to 1.8, I'm not able
to access from command line, for example, if I run* svn co* followed by the
project svn URL here is what I get:
[root@FPROD ~]# svn list https://svn-repo/svn/repos/project/trunk
Error validating server certificate
I'm happy to announce the release of Apache Subversion 1.7.14.
Please choose the mirror closest to you by visiting:
http://subversion.apache.org/download/#recommended-release
This release addresses two security issues:
CVE-2013-4505: mod_dontdothat does not restrict requests from serf clients.
I'm happy to announce the release of Apache Subversion 1.8.5.
Please choose the mirror closest to you by visiting:
http://subversion.apache.org/download/#recommended-release
This release addresses two security issues:
CVE-2013-4505: mod_dontdothat does not restrict requests from serf
Nico Kadel-Garcia wrote on Mon, Nov 25, 2013 at 05:56:14 -0500:
use the authorized_keys ForceCommand access
Minor correction: ForceCommand is a sshd_config(5) directive; the
authorized_keys variant is spelled 'command=...'.
Mehdi Hayani wrote on Mon, Nov 25, 2013 at 11:25:24 +:
- Fingerprint: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
(R)eject, accept (t)emporarily or accept (p)ermanently? p
After accepting certificate, nothing shows and it remains planted until I
tape* 'Ctrl + C* to
On Mon, Nov 25, 2013 at 3:50 PM, Daniel Shahaf d...@daniel.shahaf.name wrote:
Mehdi Hayani wrote on Mon, Nov 25, 2013 at 11:25:24 +:
- Fingerprint: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
(R)eject, accept (t)emporarily or accept (p)ermanently? p
After accepting
[Forwarding back to the list]
Mehdi Hayani wrote on Mon, Nov 25, 2013 at 21:05:42 +:
When you upgraded the server, did you also upgrade mod_dav_svn only? Or
did you also upgrade httpd and/or openssl at the same time?
I don't know what was done exactly during the update, because there is
Good point, thank you!
On Mon, Nov 25, 2013 at 3:41 PM, Daniel Shahaf d...@daniel.shahaf.name wrote:
Nico Kadel-Garcia wrote on Mon, Nov 25, 2013 at 05:56:14 -0500:
use the authorized_keys ForceCommand access
Minor correction: ForceCommand is a sshd_config(5) directive; the
authorized_keys
13 matches
Mail list logo
