1

I have a setting where only scp connections are allowed to a remote server, with ssh login being disabled (i.e. you can't get a shell into that server), and I am seeking a clean way for testing the connectivity to the remote server without transferring an actual file.

The reason for this is that the server is configured to trigger some events upon the reception of new files on users' home directories, thus, I would like to avoid triggering such events when running connectivity tests.

I will post my workaround as an answer (in case it's helpful for anyone else) but I am really looking for cleaner solutions that I haven't thought of.

PS. This question has been previously asked in Unix and Linux forum but hasn't been answered.

Anis LOUNIS aka AnixPasBesoin
  • 123
  • 6

4 Answers4

2

Consider rsync in --dry-run mode:

rsync -av --dry-run test.txt user@myserver.com:

--dry-run, -n perform a trial run with no changes made

Gilles Quénot
  • 4,226
  • 1
  • 27
  • 28
2

AFAIK the legacy scp cannot work without access to a shell on the remote side*. Please read "History, SCP and SFTP" in this answer of mine.

Since "you can't get a shell into that server" and still your scp works, it probably uses the SFTP protocol. On the server side it's possible to enable SFTP without giving access to a shell. I guess this is the case. scp using SFTP instead of SCP is the modern way.

If your scp indeed uses SFTP while connecting to the server in question, you can as well use sftp to connect. With sftp it's easy to transfer nothing:

echo bye | sftp -b - user@server

Exit status 0 means sftp successfully visited the server only to say bye.

* Except when there is no remote side. If asked to copy from local to local then scp will use cp.

Kamil Maciorowski
  • 69,815
  • 22
  • 136
  • 202
  • 1
    Possibly scp-client works because it's (recent and) using sftp, but also possibly the server is configured per-user (or globally!) with ForceCommand, or per-userkey with command=, or even per-usercert in the cert, to something that allows scp but nothing else. – dave_thompson_085 Apr 29 '23 at 01:41
1

TL;DR. Copy to /dev/null

Since in this specific use case, we are trying to avoid writing to the user's home directory, one solution would be to use /dev/null as the destination file (since it is writable by all users) and check if the file has been successfully transferred. This way, connectivity is tested while directories are kept clean.

scp test.txt user@myserver.com:/dev/null

and the output should look like

test.txt   100%   13   3.6KB/s   00:00
Anis LOUNIS aka AnixPasBesoin
  • 123
  • 6
1

OP said:

The reason for that, is the that server is configured to trigger some events upon reception of new files on the user's home directory and I don't want to trigger such events when testing.

Then the options are:

  1. You can copy it somewhere else, just outside of your home directory, like /tmp (which usually has 777 mode), or like what the OP himself is doing, copy to /dev/null.
  2. You can copy a file from the server. There are files that (almost) always exist on Unix/Linux systems, like /etc/hostname.
  3. You can copy a non existent file from the server, too. Obviously your SSH client needs to connect successfully to figure out that the file does not exist. The error message produced by the client would be different ("No such file or directory").
  4. Now having said this above. Even if your SSH disables login for you, you should still be able to use ssh or ssh -v, etc. and expect different error messages when you attempt to connect, and tell if the connection is up by parsing the error messages.
charlesz
  • 301
  • 7