Mon NAS Synology vient de mettre à jour son firmware DSM et je constate en lançant ma sauvegarde rsync que la connexion rsync vers le NAS ne se fait plus : après saisie du mot de passe, on obtient une erreur “permission denied”.
Voici comment remédier à ce petit désagrément en deux minutes montre en main.
on obtient le message d’erreur suivant, après saisie du mot de passe:
Permission denied, please try again.
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.1]
Après vérification que les identifiants (user/password) sont bien corrects, il s’avère que la solution réside dans l’utilisation de l’argument --rsync-path afin d’expliciter le chemin de l’exécutable rsync présent sur le NAS.
The OTPW package consists of the one-time-password generator otpw-gen plus two verification routinesotpw_prepare() and otpw_verify() that can easily be added to programs such as login or ftpd on POSIX systems. For platforms that support the Pluggable Authentication Method (PAM) interface, a suitable wrapper is included as well. Login software extended this way will allow reasonably secure user authentication over insecure network lines. The user carries a password list on paper. The scheme is designed to be robust against theft of the paper list and race-for-the-last-letter attacks. Cryptographic hash values of the one-time passwords are stored for verification, either in the user’s home directory or in a dedicated system directory.
Introduction
A well-known classic vulnerability of the Internet application protocol suite is the frequent cleartext transfer of passwords in the telnet, rsh, and ftp protocols. Modern replacements for these protocols such as Tatu Ylönen’sSecure Shell allow comfortable and secure remote sessions and file transfers over network connection that are not trusted to provide confidentiality.
However, traveling computer users often want to connect to their home system via untrusted terminals at conference hotels, other universities, and airports, where trusted encryption software is not available. Even Secure Shell does not protect against keyboard eavesdropping software on the untrusted terminal. A loss of confidentiality is often acceptable in these situations for the session content, but not for reusable login passwords. One-time-password schemes avoid the transmission of authentication secrets that are of any value after they have been used. This provides a reasonable level of protection against the widely encountered password sniffing attacks. The goal of a one-time-password login scheme is merely to provide a significant increase of security over the classic telnet/rlogin login procedure. It does not aim to protect from sophisticated active attacks such as session hijacking, host emulation, man-in-the-middle, etc. against which ssh and SSL based protocols should be used if this level of protection is required.
A widely known one-time-password scheme is S/KEY [Hal94, HM96]. OTPW is not compatible with and is not derived from either S/KEY or OPIE. It is a completely independent and different design, which I believe fulfils my functional and security requirements better.
How it works
One-time password authentication with the OTPW package is accomplished via a file containing hash values of passwords. Depending on the installation option chosen, this can either be a file ~john/.otpw located in the user’s home directory, or it can be a file ~otpw/john in the home directory of a dedicated pseudo user “otpw”. In the latter case, the otpw-gen tool for generating new passwords must be owned by pseudo user “otpw” and have the SETUID bit set. As long as users do not have such a hash file, the one-time-password facility is not active for them.
A user who wants to setup the one-time-password capability just executes the otpw-gen program. The program will ask for a prefix password that the user has to select and memorize and it will then write to standard output a password list such as:
Normally the output of otpw-gen should be sent directly to the printer as in
otpw-gen | lpr
or should be first formatted with an ASCII to PostScript converter where necessary.
Fetch the printed list immediately from the printer, fold it, and keep it with you. The list shows the machine name and the creation time to allow users to find the latest list for the right machine. It does not show the user’s name, because nobody is supposed to have the list of anyone else, but printer drivers such as a2ps might add it. Only a single list is required for a set of networked machines on which the user has a common home directory.
By default, otpw-gen generates 60 lines of output. Use the command line options -hlines, -wcolumns, and -spages to specify the length of the output. No more than 1000 passwords will be generated at a time.
Where one-time-password authentication is used, the password prompt will be followed by a 3-digit password number. Enter first the prefix password that was given to otpw-gen, followed directly (without hitting return between) by the password with the requested number from the printed password list:
login: kuhn
Password 019: geHeimOdAkH62c
In this example, geHeim was the prefix password. The spaces in the password list are just there to increase readability and can be dropped.
A clever attacker might observe the password being entered and might try to use the fact that computers can send data much faster than users can finish entering passwords. In the several hundred milliseconds that the user needs to press the return key after the last character, an attacker could on a parallel connection to the same machine send the code of the return key faster than the user.
To prevent such a race-for-the-last-key attack, any login attempt that is taking place concurrently with another attempt will require three one-time passwords to be entered:
This might look inconvenient at first, but remember that three passwords will only be requested when someone tries to login simultaneously, which in itself should already cause suspicion. The three requested passwords are randomly selected but they will never include the single password that was requested in the first of the concurrent login attempts. Only the first requested single password will be locked, not any of the requested triples. This way, the three-password method ensures that an attacker cannot disable the OTPW mechanism by locking all passwords. The triple challenge ensures that many ten thousand network connections would be necessary to perform a race attack on the same password triple, which is not practical. The OTPW package creates a symbolic link .otpw.lock in the user’s home directory to lock the first requested password while its input is pending. If a system crash created a stale lock, it will be removed after 24 hours.
You are running a Linux server at home, which is behind a NAT router or restrictive firewall. Now you want to SSH to the home server while you are away from home. How would you set that up? SSH port forwarding will certainly be an option. However, port forwarding can become tricky if you are dealing with multiple nested NAT environment. Besides, it can be interfered with under various ISP-specific conditions, such as restrictive ISP firewalls which block forwarded ports, or carrier-grade NAT which shares IPv4 addresses among users.
What is Reverse SSH Tunneling?
One alternative to SSH port forwarding is reverse SSH tunneling. The concept of reverse SSH tunneling is simple. For this, you will need another host (so-called « relay host ») outside your restrictive home network, which you can connect to via SSH from where you are. You could set up a relay host using a VPS instance with a public IP address. What you do then is to set up a persistent SSH tunnel from the server in your home network to the public relay host. With that, you can connect « back » to the home server from the relay host (which is why it’s called a « reverse » tunnel). As long as the relay host is reachable to you, you can connect to your home server wherever you are, or however restrictive your NAT or firewall is in your home network.
Set up a Reverse SSH Tunnel on Linux
Let’s see how we can create and use a reverse SSH tunnel. We assume the following. We will be setting up a reverse SSH tunnel from homeserver to relayserver, so that we can SSH to homeserver via relayserver from another computer called clientcomputer. The public IP address of relayserver is 1.1.1.1.
On homeserver, open an SSH connection to relayserver as follows.
Here the port 10022 is any arbitrary port number you can choose. Just make sure that this port is not used by other programs on relayserver.
The « -R 10022:localhost:22 » option defines a reverse tunnel. It forwards traffic on port 10022 of relayserver to port 22 of homeserver.
With « -fN » option, SSH will go right into the background once you successfully authenticate with an SSH server. This option is useful when you do not want to execute any command on a remote SSH server, and just want to forward ports, like in our case.
After running the above command, you will be right back to the command prompt of homeserver.
Log in to relayserver, and verify that 127.0.0.1:10022 is bound to sshd. If so, that means a reverse tunnel is set up correctly.
One thing to take note is that the SSH login/password you type for localhost should be for homeserver, not for relayserver, since you are logging in to homeserver via the tunnel’s local endpoint. So do not type login/password for relayserver. After successful login, you will be on homeserver.
When users want to have a secure connection to their MySQL server, they often rely on VPN or SSH tunnels. Yet another option for securing MySQL connections is to enable SSL wrapper on an MySQL server. Each of these approaches has its own pros and cons. For example, in highly dynamic environments where a lot of short-lived MySQL connections occur, VPN or SSH tunnels may be a better choice than SSL as the latter involves expensive per-connection SSL handshake computation. On the other hand, for those applications with relatively few long-running MySQL connections, SSL based encryption can be reasonable. Since MySQL server already comes with built-in SSL support, you do not need to implement a separate security layer like VPN or SSH tunnel, which has their own maintenance overhead.
The implementation of SSL in an MySQL server encrypts all data going back and forth between a server and a client, thereby preventing potential eavesdropping or data sniffing in wide area networks or within data centers. In addition, SSL also provides identify verification by means of SSL certificates, which can protect users against possible phishing attacks.
In this article, we will show you how to enable SSL on MySQL server. Note that the same procedure is also applicable to MariaDB server.
Creating Server SSL Certificate and Private Key
We have to create an SSL certificate and private key for an MySQL server, which will be used when connecting to the server over SSL.
First, create a temporary working directory where we will keep the key and certificate files.
$ sudo mkdir ~/cert
$ cd ~/cert
Make sure that OpenSSL is installed on your system where an MySQL server is running. Normally all Linux distributions have OpenSSL installed by default. To check if OpenSSL is installed, use the following command.
$ openssl version
OpenSSL 1.0.1f 6 Jan 2014
Now go ahead and create the CA private key and certificate. The following commands will create ca-key.pem and ca-cert.pem.
There is ongoing debate on the pros and cons of using passwords versus keys as ssh authentication methods. A main advantage of key authentication is that you can be protected against brute-force password guessing attacks. However, requiring a private key for ssh access means that you have to store the key somewhere on client system, which can be another avenue of attack.
Still, one can argue that the ramification of a cracked password is more significant than a compromised private key, because any single password tends to be used for multiple hosts and services, while the validity of a given private key is generally limited to a specific ssh server.
If you are using openssh, you can flexibly enable or disable password authentication and key authentication. Here is how to disable ssh password authentication so that you can force ssh login via public key only.
NOTE: This guide is about the SSH server side configuration for preventing password authentication and forcing key authentication. I assume that you already set up key authentication on the client side, so you can log in to SSH via key authentication (without using password). Before proceeding with the rest of this tutorial, make sure to verify this key authentication works. Otherwise, you may lose SSH access while testing this tutorial. So be careful!
Open sshd configuration file, and add the following line (or uncomment it if it’s commented out).
$ sudo vi /etc/ssh/sshd_config PasswordAuthentication no
Make sure that you have the following in /etc/ssh/sshd_config, in order to allow private/public key authentication.
RSAAuthentication yes
PubkeyAuthentication yes
Finally, reload ssh server configuration to make the change effective.
$ sudo /etc/init.d/ssh reload
The above setting will disable ssh login via password, system-wide. If what you want is to disable ssh password login for individual users, you can do the following.
If you want to disable ssh password authentication for specific users only, add the following « Match User » block at the end of sshd config file.
Match User alice,bob,john
PasswordAuthentication no
If you want to disable ssh password login for specific Linux group(s), put « Match Group » block at the end of sshd config file. For example, to disable ssh password login for all users belonging to « sudoers » group:
Match Group sudoers
PasswordAuthentication no
If you want to force ssh key authentication for non-root normal users, place the following « Match User » block at the end of sshd config file.
