Is there a way to do a remote "ls" much like "scp" does a remote copy?

You could always do this:

ssh user@host ls -l /some/directory

That will SSH to the host, run ls, dump the output back to you and immediately disconnect.

To list all files in a directory:

rsync host.name.com:directory/path/'*'

For something like find directory/path -ls

rsync -r host.name.com:directory/path

For all coming via google to this question because they are looking for a way to list remote files but can not access the remote server via ssh (common case for backup servers) you could use 'sftp'.

Example:

sftp [email protected]
ls
cd somedir
exit

Start an interactive session in a specific remote directory:

sftp [user@]host[:dir]

Yes. SSH and do an ls:

ssh host ls /path

You could easily script this to be more flexible, or use the host:path syntax scp uses.

The above answers do not contemplate when you need to add a password. To include password and username in a single command, install sshpass.

For mac: $ brew install hudochenkov/sshpass/sshpass

For linux: sudo apt-get install sshpass -y

Then:

$ sshpass -p your_password ssh user@hostname ls /path/to/dir/

You can also save output:

$ sshpass -p your_password ssh user@hostname ls /path/to/dir/ > log.txt

In python3:

import subprocess

cluster_login_email = 'user@hostname'
cluster_login_password = 'your_password'
path_to_files = '/path/to/dir/'

response = subprocess.run([
        'sshpass', '-p', cluster_login_password, 'ssh', cluster_login_email, 'ls',
        path_to_files], capture_output=True)

response = response.stdout.decode("utf-8").split('\n')

I find my most frequent use of this is to get the ls result, a simple list of files without all the permissions and dates and such, and keep it in a local file.

{ ssh [email protected] "cd /dir/of/interest; ls -1f *.txt;" } > /home/me/listoffiles.txt

You can run anything you want within the quotes. All output ends up in your local text file. Or if you want to run a big nasty script on the server and capture all of its output, even errors:

{ ssh [email protected] <script.remote.sh } > /home/me/output.log 2>/home/me/output.err

As mentioned, if you can SSH into the host, you can do whatever you like.
You can use either ssh user@host or ssh alias (defined in ~/.ssh/config)

Examples

Edit: Fixed some examples by single quoting the entire command to be sent. Thanks @dave_thompson_085 for pointing to the problem.

$ ssh user@host 'ls /dir/file'

You mentioned that you don't want to receive the errors from ls if the file does not exist.

One option is to just discard the error messages

$ ssh user@host 'ls /dir/file 2>/dev/null'

This will preserve the return as well. So $? will be 0 only if the ls command found /dir/file. This is nice because it works for files, folders, symlinks or anything that can be listed by ls.

Another option is to check if the file exists before listing.

$ ssh user@host '[ -f /dir/file ] && ls /dir/file'

You could also test and list a folder, but the syntax changes

$ ssh user@host '[ -d /dir/sub ] && ls /dir/sub'

You could chain and test for ANY as well

$ ssh user@host '[ -f /dir/file ] || [ -d /dir/file ] && ls /dir/file'

You could also just check if the item exists and nothing else

$ ssh user@host '[ -f /dir/file ] || [ -d /dir/file ]'
$ echo $? # exit code will be 0 ONLY if the file exists
0

You may want to include a test for symlinks with [ -L /my/target ] as well.

You could run conditional codes remotelly

$ ssh user@host '[ -f /dir/file ] && echo "File EXISTS!" || echo "File NOT FOUND!"'
File EXISTS!

Or locally if you move the commands outside the command string

$ ssh user@host '[ -f /dir/file ]' && echo "File EXISTS!" || echo "File NOT FOUND!"
File EXISTS!

The way quoting and expansion works can be tricky though. If you use double quotes outside the main command (instead of single quotes as above), variables will be expanded BEFORE connecting ssh, unless you escape the $. It is normally easier to use single quotes to avoid that, but your mileage may vary. Some times you need stuff to expand locally AND remotelly, which can be tricky.