to enable the automatic checking for fastest mirrors within yum install the following plugin:
$ sudo yum install yum-plugin-fastestmirror
check that plugins are enabled:
$ cat /etc/yum.conf
check that the config file contains the following:
$ cat /etc/yum/pluginconf.d/fastestmirror.conf
verbose = 0
socket_timeout = 3
enabled = 1
hostfilepath = /var/cache/yum/timedhosts.txt
maxhostfileage = 1
src: wiki.centos.org, techiecorner.com/
the install process for owncloud-client within scientific linux 7.x is quite easy (do as root):
$ cd /etc/yum.repos.d/
$ wget http://download.opensuse.org/repositories/isv:ownCloud:desktop/RedHat_RHEL-7/isv:ownCloud:desktop.repo
$ yum install owncloud-client
for password attacks one needs good password lists. the following are quite nice:
the ssh daemon is a entry point to many servers. it should be secured!!
/etc/ssh/sshd_config is secure and very restrivtive:
# COPIED FROM: https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Modern_.28OpenSSH_6.7.2B.29
# Supported HostKey algorithms by order of preference.
# Password based logins are disabled - only public key based logins are allowed.
# LogLevel VERBOSE logs user's key fingerprint on login. Needed to have a clear audit track of which key was using to log in.
# Log sftp level file access (read/write/etc.) that would not be easily logged otherwise.
Subsystem sftp /usr/lib/ssh/sftp-server -f AUTHPRIV -l INFO
# Root login is not allowed for auditing reasons. This is because it's difficult to track which process belongs to which root user:
# On Linux, user sessions are tracking using a kernel-side session id, however, this session id is not recorded by OpenSSH.
# Additionally, only tools such as systemd and auditd record the process session id.
# On other OSes, the user session id is not necessarily recorded at all kernel-side.
# Using regular users in combination with /bin/su or /usr/bin/sudo ensure a clear audit track.
# Use kernel sandbox mechanisms where possible in unprivileged processes
# Systrace on OpenBSD, Seccomp on Linux, seatbelt on MacOSX/Darwin, rlimit elsewhere.
# only 60s at login prompt
# restrive ssh folder settings
# no gui X11 features
# only specific users
AllowUsers <USER1> ...
# only ipv4
# which authorized keys
# no password login
# no tcp forwarding
# login msg
the synology’s nas boxes have their own will concerning ssh.
enable ssh service:
- at first one needs to enable the ssh service within the web-gui (link: synology.com)
- now login with the user: admin
the admin user has root privileges within the web-gui but inside the console only user privileges, but with sudo one can gain root privileges.
to enable ssh for other users. (note: this works only temporarily bc. after reboot the system resets the passwd file – crazy?!)
- open passwd file: sudo vim /etc/passwd
- change shell for specific user
- last column of the specific user’s row: /sbin/nologin -> /bin/sh
to make it a lot more secure one should login via ssh keyfiles. this needs setup within the the sshd config file. (note: ssh needs restrictive rights for the personal ~/.ssh folder and the setup on my box was somehow screwed up (synologys acl?). that’s why: StrictMode no… )
- open sshd config: sudo vim /etc/ssh/sshd_config
- change following properties:
- enable authentication by keyfile: PubkeyAuthentication yes
- load allowed client list: AuthorizedKeysFile %h/.ssh/authorized_keys
- disable folder’s rights checking: StrictModes no
- disable login via password: PasswordAuthentication no
- copy one’s public key (from the client machine) (link: digitalocean.com)
- from linux: ssh-copy-id
- from mac: scp
- from windows: ?
- restart sshd on the synology box
- synology fucked up the underlying OS such that one cannot restart the service via commandline (no init.d scripts, and their own commands (synosystemctl or so) doesnt do the job. the ssh service didnt restart…)…
- two options:
- restart the whole box
- disable and enable the ssh service inside the web-gui
the most current virtualbox version is available from the official virtualbox repository. to activate it follow this guide:
it is kinda nice to have a rsync job running while the bandwidth is not needed otherwise.
- start a
main script each night (using
main script uses
timeout to overlook the actual
# duration when the command should be killed
# which kill signal should be given
# 1: gracefully
# 9: hard?
timeout -s $KILLCMD \
rsync script as in this post rsync backup script