Timeout SFTP 4GB limit ext4 Postgresql SSH rsync rsa[Solved]

[LleMikeByw]

Hi Flavio,

I have a couple of questions (Q) and then a couple of comments (C) which might begin to point you in the right direction to resolve this situation yourself (I hope ):

Also note that the really interesting stuff may start at C7... (Until there it's mostly confirmation of understanding).

Q1) Please confirm that you can definitely login without password to each DiskStation i.e. you have copied each client's public RSA key from the client machine to the DiskStation you are trying to log into. The public key of the client machine would be originally stored where you told the client machine to store it (on the client PC ) - for me that is /etc/ssh on my Linux PC. You may have stored it elsewhere.

Q2) Please confirm you have then copied the client's RSA key to either of the following folders on the DiskStation:
a) FOR AN USER: If you are logging in as a non-root user to the DiskStation that the client's RSA key is stored in this folder:

Code: Select all

/volume1/homes/UsersFolder/.ssh

b) FOR ROOT: If you are logging in as root that the client's RSA key is stored in this alternative folder:

Code: Select all

/root/.ssh

C1) Both of those folders would be on the DiskStation you are trying to log into.

C2) If you have done that then you should be able to login to the DiskStation via SSH without a password. SSH is handling the authorisation for this setup.

C3) Now to use RSYNC from a client PC with this simple setup you must ensure it uses SSH to handle the authorisation and encryption.

C4) So when I run my RSYNC command from a Linux client I FORCE it to utilise SSH by using the option ssh in this command (see the ssh? Look! There! There's a 'ssh' in the options for command - See it? Just before "--progress" ):

Code: Select all

rsync -vrtplze ssh --progress --stats --delete /home/Mike/Documents Mike@192.168.XXX.XX1:/volume1/homes/Mike/ExampleFolder

C5) Take note that the rsync command is issued on the CLIENT PC.

C6) The client PC contacts the SSHD server on the DiskStation, does a login and then does the rsyncing through ssh.

C7) From your post it seems to me that you are issuing the rsync command on the DiskStation - NOT a client PC - and seeking to contact a rsync server on your 'client' PC.

C8) If you were issuing a rsync command (over ssh) on the DiskStation you need to reverse ENTIRELY the authorisations i.e. the DiskStation's RSA public key would need to be transferred to the "client" PCs and a SSH server would have to be running on the "client" PCs.

C9) If however, you are expecting to communicate from your DiskStation to just a rsync server on another PC/DiskStation without going over ssh then you will not be able to utilise password-less login UNLESS you employ the --password-file option from the DiskStation. User details are held in rsyncd.secrets on the server but will require the pass-phrase to be communicated when your rsync command tries to log in taking the password from the local file on the DiskStation (Not ideal - I don't think - but it's your choice...).

C10) However, I assume you have a SSH daemon running on the device to which you wish to rsync. Consequently, it would appear to me that what is happening here is that the RSA key of the problematic DiskStation has not been transferred to the device to which you are seeking to rsync over ssh.

C11) I note you have "upgraded" the problematic DiskStation. It is possible - if the DiskStation was working previously - that your previous configuration files have been over-written during the "upgrade" (Don't start me off on that ) INCLUDING it's rsa public key .

C12) Consequently, I would transfer a new RSA public key from the inoperative DiskStation to the server you are trying to login to and try again.

C13) Briefly, you have mentioned PAM authorisation. This is unlikely to be a cause of your problem.

PAM is more concerned with number of logins or length of login rather than authorisation methodology and wouldn't affect outward traffic run as root.

Mike

[FlavioB]

Hi Flavio,

Hello Mike and thanks for gettin back to me. I've gone through your Q's and C's, now I'll answer them step by step...

Q1) Please confirm that you can definitely login without password to each DiskStation i.e. you have copied each client's public RSA key from the client machine to the DiskStation you are trying to log into. The public key of the client machine would be originally stored where you told the client machine to store it (on the client PC ) - for me that is /etc/ssh on my Linux PC. You may have stored it elsewhere.

Q2) Please confirm you have then copied the client's RSA key to either of the following folders on the DiskStation:
a) FOR AN USER: If you are logging in as a non-root user to the DiskStation that the client's RSA key is stored in this folder:

Code: Select all

/volume1/homes/UsersFolder/.ssh

b) FOR ROOT: If you are logging in as root that the client's RSA key is stored in this alternative folder:

Code: Select all

/root/.ssh

As I'm connecting as root, I checked and I have in /root/.ssh/ this:

Code: Select all

DiskStation> pwd
/root
DiskStation> cd .ssh/
DiskStation> ls -la
drwx------    2 root     root          4096 Mar  1 17:46 .
drwxr-xr-x    3 root     root          4096 Mar 25 18:14 ..
-rw-------    1 root     root           399 Mar  1 17:46 authorized_keys


C1) Both of those folders would be on the DiskStation you are trying to log into.

Yes, they are.

C2) If you have done that then you should be able to login to the DiskStation via SSH without a password. SSH is handling the authorisation for this setup.

I'm logging in on both the DSM 2.3 and DSM 3.1 without having to type any password, thus the ssh part is working ok.

C3) Now to use RSYNC from a client PC with this simple setup you must ensure it uses SSH to handle the authorisation and encryption.

C4) So when I run my RSYNC command from a Linux client I FORCE it to utilise SSH by using the option ssh in this command (see the ssh? Look! There! There's a 'ssh' in the options for command - See it? Just before "--progress" ):

Code: Select all

rsync -vrtplze ssh --progress --stats --delete /home/Mike/Documents Mike@192.168.XXX.XX1:/volume1/homes/Mike/ExampleFolder

C5) Take note that the rsync command is issued on the CLIENT PC.

C6) The client PC contacts the SSHD server on the DiskStation, does a login and then does the rsyncing through ssh.

C7) From your post it seems to me that you are issuing the rsync command on the DiskStation - NOT a client PC - and seeking to contact a rsync server on your 'client' PC.

Let's stop here and explain what I do.
I'll be showing you the configuration files of a working DS209j.
On my BackupPC Linux box:

Code: Select all

$ ssh root@remoteIP


BusyBox v1.1.0 (2010.04.19-13:38+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

DS209> rsync rsync://localhost/
Documenti
Wabal
Sage
DS209> rsync rsync://localhost/Sage/
drwxrwxrwx       4096 2011/04/05 15:38:46 .
-rwxrwxrwx    8497152 2011/02/17 09:09:04 FY_PLUTO.001
-rwxrwxrwx    8273920 2011/01/27 09:32:33 FY_plutosa.001
-rwxrwxrwx    8273920 2011/01/27 09:30:22 PL_plutosa.001
-rw-r--r--          0 2010/09/03 08:06:54 test.txt
-r-xr-xr-x   49207296 2011/04/05 15:38:46 wz_PLUTO.mdb
-rwxrwxrwx   20523008 2011/02/17 08:29:25 wz_plutosa.BK1
-rwxrwxrwx   20523008 2011/02/16 09:18:41 wz_plutosa.BK2
-rwxrwxrwx          0 2010/10/05 09:12:19 wz_plutosa.BKP
drwxrwxrwx       4096 2011/02/17 09:27:45 old


Therefore, as you can see, I am able to connect to my DS and on that DS I can use rsync without typing passwords.
Here the relevant configuration files:
RSYNC:

Code: Select all

DS209> cat /etc/rsyncd.conf
#motd file = /etc/rsyncd.motd
#log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
use chroot = no
#[NetBackup]
#path = /var/services/NetBackup
#comment = Network Backup Share
#uid = root
#gid = root
#read only = no
#list = yes
#charset = utf-8
#auth users = root
#secrets file = /etc/rsyncd.secrets
[Documenti]
path = /volume1/Documenti
read only = no
transfer logging = yes
[Wabal]
path = /volume1/Wabal
read only = no
transfer logging = yes
[Sage]
path = /volume1/SAGE
read only = no
transfer logging = yes


SSHD:

Code: Select all

DS209> cat /etc/ssh/sshd_config
#       $OpenBSD: sshd_config,v 1.80 2008/07/02 02:24:18 djm Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require explicit
# activation of protocol 1
Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys

#now ssh is only used by rsync ==> auth by passwd file of rsync server
#AuthPassFile /etc/rsyncd.secrets

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM no

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
#ChrootDirectory none

#DenyUsers admin

# no default banner path
#Banner none

# override default of no subsystems
Subsystem       sftp    /usr/libexec/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       ForceCommand cvs server


C8) If you were issuing a rsync command (over ssh) on the DiskStation you need to reverse ENTIRELY the authorisations i.e. the DiskStation's RSA public key would need to be transferred to the "client" PCs and a SSH server would have to be running on the "client" PCs.

C9) If however, you are expecting to communicate from your DiskStation to just a rsync server on another PC/DiskStation without going over ssh then you will not be able to utilise password-less login UNLESS you employ the --password-file option from the DiskStation. User details are held in rsyncd.secrets on the server but will require the pass-phrase to be communicated when your rsync command tries to log in taking the password from the local file on the DiskStation (Not ideal - I don't think - but it's your choice...).

Well, I can't relate to C8 and C9, because I am sure that I never reversed authorisations (C8): the public key is originated on my BackupPC server and transferred over to remote DiskStations.
And I also don't expect to communicate without ssh tunnel (C9).

C10) However, I assume you have a SSH daemon running on the device to which you wish to rsync. Consequently, it would appear to me that what is happening here is that the RSA key of the problematic DiskStation has not been transferred to the device to which you are seeking to rsync over ssh.

As said before, I don't need to have RSA keys of any DS, because I'm not running BackupPC in that direction.

C11) I note you have "upgraded" the problematic DiskStation. It is possible - if the DiskStation was working previously - that your previous configuration files have been over-written during the "upgrade" (Don't start me off on that ) INCLUDING it's rsa public key .

I did not upgrade the problematic DS: when it came out of the box I installed the DSM, and as you know you get the latest available version to install on. That was (2 weeks ago) 3.1-1605.
The working DiskStations have DSM 2.3 because I installed them both more than one year ago.

C12) Consequently, I would transfer a new RSA public key from the inoperative DiskStation to the server you are trying to login to and try again.

C13) Briefly, you have mentioned PAM authorisation. This is unlikely to be a cause of your problem.

PAM is more concerned with number of logins or length of login rather than authorisation methodology and wouldn't affect outward traffic run as root.

Mike

Again, thanks for taking your time and being detailed.
What I'd like to do now is to show you the configuration files of the faulty DS:

RSYNC:

Code: Select all

DiskStation> cat /etc/rsyncd.conf
#motd file = /etc/rsyncd.motd
#log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
use chroot = no
[Dati]
path =  /volume1/Dati
read only = no
transfer logging = yes
hosts allow = *
#auth users = *
#secrets file = /etc/rsyncd.secrets


SSHD:

Code: Select all

DiskStation> cat /etc/ssh/sshd_config
#       $OpenBSD: sshd_config,v 1.80 2008/07/02 02:24:18 djm Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require explicit
# activation of protocol 1
Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys

#now ssh is only used by rsync ==> auth by passwd file of rsync server
#AuthPassFile /etc/rsyncd.secrets

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM yes
UsePAM no

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
#ChrootDirectory none

#DenyUsers admin

# no default banner path
#Banner none

# override default of no subsystems
#Subsystem      sftp    /usr/libexec/sftp-server
#Subsystem       sftp    internal-sftp

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       ForceCommand cvs server


What do you see and where do you think I got wrong?

Thanks again!
F.

[LleMikeByw]

Flavio,

I understand a bit more now.

I see the following:

1) Have you enabled the SFTP server on the DiskStation on which you are seeking to run the RSYNC? Note this in the SSHD config file of the non-functioning DS:

Code: Select all

# override default of no subsystems
#Subsystem      sftp    /usr/libexec/sftp-server
#Subsystem       sftp    internal-sftp

Firstly, you should ensure through the Web Interface that SFTP is the preferred FTP (Allow SSL/TLS connection only), then just uncomment the first SubSystem line in the SSHD config file on the apparently non-functioning DiskStation (if it isn't already). Remember to reboot.

2) PAM authorisation appears to have been originally preferred. It does affect logins and who can run which application (in it's most advanced form - but you are logged in as root). Whatever, I note you have altered it in sshd_config:

Code: Select all

# and ChallengeResponseAuthentication to 'no'.
#UsePAM yes
UsePAM no

So, have you rebooted the DiskStation since changing the setting (Just checking here)?

3) Finally, it shouldn't be having an effect but let's just explicitly state that root can do things on your non-functioning DiskStation so change the rsyncd.conf file by adding the following (un-commented) lines (I know * should allow it - but let's get root working first):

Code: Select all

uid = root
gid = root
auth users = root
secrets file = /etc/rsyncd.secrets

4) Once you've made the above changes - reboot that DiskStation and see what happens now...

5) If those don't work add the following lines to sshd_config:

Code: Select all

RSAAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
AllowUsers root

Using a sledgehammer - but let's clear all possible barriers... and reboot... then try again.

Mike

[FlavioB]

Hello Mike...

Flavio,

I understand a bit more now.

I see the following:

1) Have you enabled the SFTP server on the DiskStation on which you are seeking to run the RSYNC? Note this in the SSHD config file of the non-functioning DS:

Code: Select all

# override default of no subsystems
#Subsystem      sftp    /usr/libexec/sftp-server
#Subsystem       sftp    internal-sftp

Firstly, you should ensure through the Web Interface that SFTP is the preferred FTP (Allow SSL/TLS connection only), then just uncomment the first SubSystem line in the SSHD config file on the apparently non-functioning DiskStation (if it isn't already). Remember to reboot.

I don't know what sftp has to do with rsync/ssh, but I simply followed your suggestion and uncommented the first line you indicated.
BTW I've to say that on the working (older) DiskStations, no ftp or sftp is enabled.

2) PAM authorisation appears to have been originally preferred. It does affect logins and who can run which application (in it's most advanced form - but you are logged in as root). Whatever, I note you have altered it in sshd_config:

Code: Select all

# and ChallengeResponseAuthentication to 'no'.
#UsePAM yes
UsePAM no

So, have you rebooted the DiskStation since changing the setting (Just checking here)?

I double-checked and "UsePAM no" is uncommented.
I rebooted after every single point you suggested... (I know we're just checking, but better check the "stupid" things too!)

3) Finally, it shouldn't be having an effect but let's just explicitly state that root can do things on your non-functioning DiskStation so change the rsyncd.conf file by adding the following (un-commented) lines (I know * should allow it - but let's get root working first):

Code: Select all

uid = root
gid = root
auth users = root
secrets file = /etc/rsyncd.secrets

Here you can see the file. I have changed the DS because I can't reboot the one installed, thus I am using my private one which I have at home and remotely connected. Thus the different "module" names...

Code: Select all

DiskStation> cat /etc/rsyncd.conf
#motd file = /etc/rsyncd.motd
#log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
use chroot = no
[NetBackup]
path = /var/services/NetBackup
comment = Network Backup Share
uid = root
gid = root
read only = no
list = yes
charset = utf-8
auth users = root
secrets file = /etc/rsyncd.secrets
[musica]
path = /volume1/musica
uid = root
gid = root
read only = no
list = yes
charset = utf-8
auth users = root
secrets file = /etc/rsyncd.secrets


4) Once you've made the above changes - reboot that DiskStation and see what happens now...

Nothing changed: after logging in (passwordless) with ssh, rsync still asks for a password.

5) If those don't work add the following lines to sshd_config:

Code: Select all

RSAAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
AllowUsers root

Here my sshd_config:

Code: Select all

DiskStation> cat /etc/ssh/sshd_config
#       $OpenBSD: sshd_config,v 1.80 2008/07/02 02:24:18 djm Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require explicit
# activation of protocol 1
Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

#now ssh is only used by rsync ==> auth by passwd file of rsync server
#AuthPassFile /etc/rsyncd.secrets

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM yes
UsePAM no

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
#ChrootDirectory none

#DenyUsers admin

# no default banner path
#Banner none

# override default of no subsystems
Subsystem       sftp    /usr/libexec/sftp-server
#Subsystem       sftp    internal-sftp

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       ForceCommand cvs server


Using a sledgehammer - but let's clear all possible barriers... and reboot... then try again.

Mike

What more can we try to do?
I really feel that Synology somehow changed something when compiling rsync for DSM 3.1-1605...
I'm still waiting for their support to tell me which further steps to take, in the meantime I'm thanking you for your kind and detailed support.

If you'd like to, we can arrange to have some sort of "double attack" on my DS: via Skype/chat and remote logins, we could eventually cooperate...

Regards,
F.

[LleMikeByw]

Flavio,

Code: Select all

I don't know what sftp has to do with rsync/ssh

: you correctly surmised that I am seeking to remove differences to eliminate untoward interactions.

Via an RSA'd ssh session on my DiskStation I changed the name of rsyncd.secrets and issued a simple rsync and did not have to enter a password. However, I am not using modules.

So I would suggest that your ssh is working fine and authorisation is arising due to rsync configuraton or rsync itself

So:

1) rsync configuration: I mentioned before that you might have to provide your rsync command with a password file:

Code: Select all

rsync --password-file=/path/to/a/password/file

It would be worthwhile trying this to see if the modules commands run with the password file in place - in which case we know we can focus on rsyncd.conf. The password file would contain your root password. Ensure you

Code: Select all

chmod 600

2) rsync.secrets: Please

Code: Select all

cat rsync.secrets

to ensure it isn't empty. Is it at all possible that rsync.secrets contains a different password for root? I ask you to cat it to ensure it isn't empty.

3) Shock and Awe solution: If you are concerned that rsync itself was compiled with additional security settings in 1605 (I am busy on something else currently or would spend some time checking the source) then you could IPKG your DiskStation and then install the ipkg version of rsync. Personally I'd do this anyway.

4) Ray Quick (The Specialist) method Go back to a previous version of DSM via the changing version number method and down-grading your DiskStation. Although a clean wipe is probably the overall best solution. I am interested if Synology will suggest this

Let's see what comes of these suggestions...

Mike

[FlavioB]

Back again...

So:

1) rsync configuration: I mentioned before that you might have to provide your rsync command with a password file:

Code: Select all

rsync --password-file=/path/to/a/password/file

It would be worthwhile trying this to see if the modules commands run with the password file in place - in which case we know we can focus on rsyncd.conf. The password file would contain your root password. Ensure you

Code: Select all

chmod 600

/etc/rsyncd.secrets actually was not chmod 600, instead it was 640. I changed it to 600.
I tried again in a passwordless ssh session to "rsync rsync://localhost/musica" but still I had to type the password.

2) rsync.secrets: Please

Code: Select all

cat rsync.secrets

to ensure it isn't empty. Is it at all possible that rsync.secrets contains a different password for root? I ask you to cat it to ensure it isn't empty.

Code: Select all

DiskStation> cat /etc/rsyncd.secrets
root:on21L5tT4GGsg|pN3N5Xmr5rANBPM=



Note that there is an empty line after the "root" line...
And, BTW: is it ok that the password is somehow "encrypted"?
I can assure that the password I type when rsync asks me to, is the same I type when I log in with root via ssh (when doing it from a host which is not allowed to login without password).

3) Shock and Awe solution: If you are concerned that rsync itself was compiled with additional security settings in 1605 (I am busy on something else currently or would spend some time checking the source) then you could IPKG your DiskStation and then install the ipkg version of rsync. Personally I'd do this anyway.

OK, I'll consider this one too...

4) Ray Quick (The Specialist) method Go back to a previous version of DSM via the changing version number method and down-grading your DiskStation. Although a clean wipe is probably the overall best solution. I am interested if Synology will suggest this

Let's see what comes of these suggestions...

Mike

The last suggestion is something I thought of too, but I cannot afford to wipe and install some 2.3 DSM because this DS is actually in use!

F.

[LleMikeByw]

Flavio,

I should have checked the forum more thoroughly before...

This situation has been covered by others before, here:

http://forum.synology.com/enu/viewtopic.php?f=160&t=34661&start=0&hilit=rsync+3.1

I personally run DSM3.0 and don't use modules so had not encountered the described behaviour myself - nor had real reason to resolve the matter.

The thread above appears to offer an actual solution. I am particularly interested in the comment that rsync is run as admin user. That is absolutely the problem!

I'll have a closer look at this when I have a little more time.

Mike

P.S. I've read what's been written now... The service is started as an admin service... that can be circumvented ... stop the rsync server elegantly from root and restart it... do I need to draw pictures? <<<<<< I've posted a query on the other thread... perhaps you can post the results of my instructions. Thanks.

P.P.S. Synology - why, why, why???

[FlavioB]

Flavio,

I should have checked the forum more thoroughly before...

Well, I also did not search the forums...

This situation has been covered by others before, here:

http://forum.synology.com/enu/viewtopic.php?f=160&t=34661&start=0&hilit=rsync+3.1

I'll be posting on over there, it makes more sense and it's better related to the problem I'm experiencing, OK?

Catch ya on the other thread.

Thanks again!
F.

[inteq]

Good info
But, I am stuck on rsync+ssh from a windows machine to DS
No matter what I try, I keep getting asked for password.
With Delta Copy and root account it works. But when I try to run it with a user limited account, I am lost
Any info for rsync over ssh with rsa auth from a windows machine?

[LleMikeByw]

Hello inteq,

First
If you are running DSM3.1 and have not IPKG'd your DiskStation then...

There is a problem that with the upgrade to DSM3.1 Synology changed the configuration of rsync - meaning that the process is run with admin authority not root.

Consequently, even if you log in as root - you still have to enter a password when doing anything with rsync.

The solution is to IPKG your DiskStation, and install the IPKG version of rsync instead of the resident version.

IPKG'ing your DiskStation is not a difficult task (and has been done by many on this forum) and opens a gateway to a range of new packages. Described here:
http://forum.synology.com/wiki/index.php/Overview_on_modifying_the_Synology_Server,_bootstrap,_ipkg_etc

Once done... follow my earlier instructions to install rsync 3.0.7...

Second

If you find the problem still occuring when you've changed the rsync server then you haven't transferred the RSA keys to the correct directories for the under-privileged users on the DiskStation. You need to look closely at my posts (further up in this thread), here:

http://forum.synology.com/enu/viewtopic.php?f=15&t=31332#p134474


and

http://forum.synology.com/enu/viewtopic.php?f=15&t=31332#p134976

You MUST create RSA keys for EACH un-privileged user in their directory on the DS AND the keys must be present in the relevant directory on your Windows client. I'm not doing SSH from a Windows PC - so cannot confirm the relevant directory from a Windows PC. I suggest you have a close look at this page which should help you with the Windows setup:

http://ist.berkeley.edu/as-ag/tools/howto/ssh-key-exchange-win.html#Copy+user%27s+public+key+to+server

If you need assistance on other steps - just look at the earlier postings in this thread.

Mike

[LleMikeByw]

If anybody's interested... since my 8 hour regular backups were working thru' crontab I didn't do anything on the OpenSuse shutdown scripts earlier.

I expect to return to that shortly (been so flaming busy!!!!!!!!!!!!!!!)

Mike

[LleMikeByw]

With the release of openSUSE 12.1 - openSUSE deployed systemd as a replacement for init - and I moved my platforms to Gentoo Linux which uses OpenRC.
Consequently I will not be posting shutdown scripts for openSUSE in this thread.
Meanwhile, if you are interested in secure platforms, take a look at OpenBSD - high security with Apache and Bind installed by default - and rsync available through Ports.
Mike