[SOLVED] SSH problem

JohnDeere630 · 11-30-2020, 01:03 AM

Hello,
I haven't posted here in forever, but I have a problem that someone here may be able to at least point me in the right direction. I don't know what information may be relevant, so please forgive my verbosity.

The setup: I have a linux Debian laptop and an Openmediavault NAS server that I built some years ago, and both are working fine. Recently, I decided to try and use rsync over ssh to keep my laptop backed up on the server. I used a number of sources to set up ssh and the keys and all that. So far so good.

The problem is that now, I can ssh into the server's root directory, and do whatever I want, but I cannot for the life of me figure out how to ssh into the shared folders on the server. I have the root filesystem installed on a small SSD, and the actual storage is on a RAID 5 array. SSH says it can't chdir into /home/gary because the file does not exist. The /home directory on the SSD does not contain anything, as the folders are all on the RAID array.

I suspect whatever is wrong is probably pretty elementary, but I'll be damned if I can see it.

Any help is greatly appreciated, and I would be happy to post any other needed info. Thank you!

Turbocapitalist · 11-30-2020, 01:47 AM

If you do have any kind of interactive session over SSH on the NAS, then you could look at what is there for clues:

Code:

df -hP | sed -n '1p;/^\//p'
du -sh /* 2>/dev/null | sort -hr | head
echo ${HOME}

The SSH client passes the control over to the designated shell on the NAS once an interactive session is established, so the error is probably not caused by SSH per se rather by what is going on over on the NAS. Can you show the options you are using with rysnc and how you are trying to connect with ssh? The former would be especially interesting since it works. Post sanitized examples if you feel it necessary.

berndbausch · 11-30-2020, 01:47 AM

It should not be too hard to figure out where the RAID array is mounted. Commands that come to mind: df, lsblk, blkid.

Also, what technology is used to share folders? NFS, Samba, something else? The configuration of the sharing technology, such as /etc/samba/smb.conf or /etc/exports, tells you where the shared folders are.

EDIT: Also /etc/fstab.

JohnDeere630 · 11-30-2020, 02:21 AM

Quote:

Originally Posted by Turbocapitalist

If you do have any kind of interactive session over SSH on the NAS, then you could look at what is there for clues:

Code:

df -hP | sed -n '1p;/^\//p'
du -sh /* 2>/dev/null | sort -hr | head
echo ${HOME}

The SSH client passes the control over to the designated shell on the NAS once an interactive session is established, so the error is probably not caused by SSH per se rather by what is going on over on the NAS. Can you show the options you are using with rysnc and how you are trying to connect with ssh? The former would be especially interesting since it works. Post sanitized examples if you feel it necessary.

Thanks for the reply! The results of the commands you posted:

Code:

gary@debian:~$ ssh gary@192.168.1.138
gary@192.168.1.138's password: 
Linux openmediavault.local 5.4.0-0.bpo.4-amd64 #1 SMP Debian 5.4.19-1~bpo10+1 (2020-03-09) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Nov 29 23:09:12 2020 from 192.168.1.110
Could not chdir to home directory /home/gary: No such file or directory
gary@openmediavault:/$ df -hP | sed -n '1p;/^\//p'
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        51G  1.8G   47G   4% /
/dev/sda1       511M  140K  511M   1% /boot/efi
/dev/md127      3.6T  366G  3.3T  10% /srv/dev-disk-by-label-server
gary@openmediavault:/$ du -sh /* 2>/dev/null | sort -hr | head
367G    /export
1.3G    /usr
312M    /var
61M     /boot
51M     /run
6.6M    /etc
1.7M    /srv
16K     /lost+found
8.0K    /media
4.0K    /sharedfolders
gary@openmediavault:/$ echo ${HOME}
/home/gary
gary@openmediavault:/$

JohnDeere630 · 11-30-2020, 02:27 AM

Quote:

Originally Posted by berndbausch

It should not be too hard to figure out where the RAID array is mounted. Commands that come to mind: df, lsblk, blkid.

Also, what technology is used to share folders? NFS, Samba, something else? The configuration of the sharing technology, such as /etc/samba/smb.conf or /etc/exports, tells you where the shared folders are.

EDIT: Also /etc/fstab.

I added 2 lines in /etc/fstab to mount the shared folders in /home/gary/OMV:

Code:

//192.168.1.138/Gary /home/gary/OMV/Gary cifs uid=1000,username=gary,password=%45hnB4$,iocharset=utf8 0 0
//192.168.1.138/QuantumHarvest /home/gary/OMV/QuantumHarvest cifs uid=1000,username=gary,password=%45hnB4$,iocharset=utf8 0 0

I am running rsync using the mounted shares as local folders

PS, I'm not worried about redacting anything, as there isn't anything on the server that could possibly interest anyone....

Turbocapitalist · 11-30-2020, 03:26 AM

Between what you have in fstab and the disk usage, it looks like you have Samba / CIFS and your data is somewhere under /export on the NAS. I'm not familiar with Samba anymore, I dropped it when I discovered sshfs a long time ago. However, once you find your data, probably under /export, you should be able to change your home directory.

Code:

sudo usermod -d /export/whatever gary

As for the redactions, the data might or might not be interesting but the bandwidth always is and the CPU, even if meager, is too.

michaelk · 11-30-2020, 04:26 AM

Looks like the raid is /srv/... versus /export but depends on the smb.conf.

If you look at the smb.conf file on the server you can find the real path to the gary share which I assume is the desired path and just cd to the location. There are several ways to automate this.

https://serverfault.com/questions/49...0a%20directory.

JohnDeere630 · 12-01-2020, 01:41 PM

Thank you both! I think I have it now. The information you provided gave me at least a general idea of where to look and what to search for. It's hard doing a google search when one doesn't have the faintest idea what to look for. I'm running rsync currently, and when it finishes, I'll reset the passwords and set it up as a cron job. Thanks again!

JohnDeere630 · 12-01-2020, 01:48 PM

As an aside, vis-a-vis security, the NAS is connected via Cat5 to the router, and neither has internet access. I access the internet via bluetooth tether to my cell phone on the lappy. Anyone that can hack into that mess and retrieve my collection of antique tractor, WW2 fighter plane, and cat pics is welcome to them, LOL. Of course, I'd also freely send them to anyone who asks......

JohnDeere630 · 12-01-2020, 07:03 PM

For anyone that stumbles on this thread in a search, the underlying problem was that I was trying to rsync into the NAS as my NAS user. It turns out that all I had to do was change gary@<NAS-address> to root@<NAS-address>. I also was able to find the correct path I needed thanks to the replies I received here.

Once I redid the ssh keys using a simple howto I found, (in case the link disappears, I'll post the relevant steps): {please excuse the grammar, as the OP is from Egypt, LOL}

Quote:

...now we need to access without a password, so we will create certificate to let the server know us, it's recommended to create a different certificate for each server for security purpose. follow me to create your certificate and copy it to the server.

Code:

# ssh-keygen -t rsa

Generating public/private rsa key pair.

Enter file in which to save the key (/home/a/.ssh/id_rsa):

Created directory '/home/a/.ssh'.

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/a/.ssh/id_rsa.

Your public key has been saved in /home/a/.ssh/id_rsa.pub.

The key fingerprint is:

3e:4f:05:79:3a:9f:56:7c:3b:ad:e9:57:37:bc:37:s4 a@A

Now copy the certificate to your server and enter your server password one last time.

Code:

# cat .ssh/id_rsa.pub | ssh root@123.45.67.89 'cat >> .ssh/authorized_keys'

No more ssh with password

That did the trick. Now the rsync command, added to the cron list:

Code:

0 3 * * * rsync -ae 'ssh -p <port>' --delete --exclude '.cache' /<Source path>/ root@<ServerIP>:/<Destination path>/

Note that the values in italics will be unique to your setup. If you don't specify a port for ssh, it defaults to port 22.
I hope this helps someone.

Turbocapitalist · 12-01-2020, 09:18 PM

For it to go automatically, you'll also have to point to the key file:

Code:

0 3 * * * rsync -ae 'ssh -p <port> -i /root/.ssh/id_rsa' --delete --exclude '.cache' /<Source path>/ root@<ServerIP>:/<Destination path>/

As an added lock-down measure, especially because it is root, you ought to restrict the key to just rsync, at least out of principle if for no other reason.

You can find out what the command and options the server is receiving if you connect that way manually once adding in verbose SSH.

Code:

rsync -ae 'ssh -v -E /tmp/ssh-client.log -p <port> -i /root/.ssh/id_rsa' \
        --delete --exclude '.cache' \
        /<Source path>/ root@<ServerIP>:/<Destination path>/

It will show you what to put in /root/.ssh/authorized_keys inside the file /tmp/ssh-client.log. There you will see,

Code:

...
debug1: Sending command: rsync --server -logDtpre.iLsfxC --delete . /<Destination path>/
...

Take that and paste it into your remote machine's /root/.ssh/authorized_keys file at inside the command="..." part which you will now add:

Code:

command="/usr/bin/rsync --server -logDtpre.iLsfxC --delete . /<Destination path>/" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC1Oju82Ocm/dgeShgYqvA9Z82XiS5UGwlOYtYp1MhrDHvbg7S+Gv4lojCjwX8Uo5COJLPfw6Gb5GtzD8zJbUtEqGrz7P+vWDUZxTrIqFxG+pKwKfE5+TdUi4mdd9nuWTYubNX8gav/huymZ2nrbz0XTaFKFYUrSI66rmome1htwXiEJJo2K0FgZl72UL8gm+2G6CLWF6N9y2Y8E7PhLzJKQuRD45//6bvXw93eJwnzu07oTigR+CzDbPJyB9M/hYylIs2fWCWN0DwYdsGx4f20Uyy9EJ/r96cCdnQDQ13C+EX+Avzh2ZDJD5uOWmofkNcC1SAxRrqOQHQNvTaqme61hM0Wf0gJCRYA9F5m51ZdDlchDXp32/IOUd1VKpcd45NquVIEePKED+rDDvrpBuso83ouQi/V8Wdo/0Zfg8Wd0K4WPdUjq4dEFrk5wpsIkFJXuHlhV3eYM5eXYi14LWbdgf4p5cbe94EEOEbr+Z/5LIN2/JBArCUkUkwGOWAUqFU=

Test it manually to make sure you can still use the rsync formula from the cron job.

That arrangement will prevent the key from being used for anything other than Rsync to that particular destination path.

JohnDeere630 · 12-01-2020, 11:42 PM

Quote:

Originally Posted by Turbocapitalist

For it to go automatically, you'll also have to point to the key file:

Code:

0 3 * * * rsync -ae 'ssh -p <port> -i /root/.ssh/id_rsa' --delete --exclude '.cache' /<Source path>/ root@<ServerIP>:/<Destination path>/

As an added lock-down measure, especially because it is root, you ought to restrict the key to just rsync, at least out of principle if for no other reason.

You can find out what the command and options the server is receiving if you connect that way manually once adding in verbose SSH.

Code:

rsync -ae 'ssh -v -E /tmp/ssh-client.log -p <port> -i /root/.ssh/id_rsa' \
        --delete --exclude '.cache' \
        /<Source path>/ root@<ServerIP>:/<Destination path>/

It will show you what to put in /root/.ssh/authorized_keys inside the file /tmp/ssh-client.log. There you will see,

Code:

...
debug1: Sending command: rsync --server -logDtpre.iLsfxC --delete . /<Destination path>/
...

Take that and paste it into your remote machine's /root/.ssh/authorized_keys file at inside the command="..." part which you will now add:

Code:

command="/usr/bin/rsync --server -logDtpre.iLsfxC --delete . /<Destination path>/" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC1Oju82Ocm/dgeShgYqvA9Z82XiS5UGwlOYtYp1MhrDHvbg7S+Gv4lojCjwX8Uo5COJLPfw6Gb5GtzD8zJbUtEqGrz7P+vWDUZxTrIqFxG+pKwKfE5+TdUi4mdd9nuWTYubNX8gav/huymZ2nrbz0XTaFKFYUrSI66rmome1htwXiEJJo2K0FgZl72UL8gm+2G6CLWF6N9y2Y8E7PhLzJKQuRD45//6bvXw93eJwnzu07oTigR+CzDbPJyB9M/hYylIs2fWCWN0DwYdsGx4f20Uyy9EJ/r96cCdnQDQ13C+EX+Avzh2ZDJD5uOWmofkNcC1SAxRrqOQHQNvTaqme61hM0Wf0gJCRYA9F5m51ZdDlchDXp32/IOUd1VKpcd45NquVIEePKED+rDDvrpBuso83ouQi/V8Wdo/0Zfg8Wd0K4WPdUjq4dEFrk5wpsIkFJXuHlhV3eYM5eXYi14LWbdgf4p5cbe94EEOEbr+Z/5LIN2/JBArCUkUkwGOWAUqFU=

Test it manually to make sure you can still use the rsync formula from the cron job.

That arrangement will prevent the key from being used for anything other than Rsync to that particular destination path.

Wow! Thank you! It seemed to work, but I will do as you suggest.