Don't use a password. Generate a passphrase-less SSH key and push it to your VM.
If you already have an SSH key, you can skip this step…
Just hit Enter for the key and both passphrases:
$ ssh-keygen -t rsa -b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/id_rsa.pub.
Copy your keys to the target server:
$ ssh-copy-id id@server
id@server's password:
Now try logging into the machine, with ssh 'id@server', and check-in:
.ssh/authorized_keys
Note: If you don't have .ssh dir and authorized_keys file, you need to create it first
to make sure we haven’t added extra keys that you weren’t expecting.
Finally, check to log in…
$ ssh id@server
id@server:~$
You may also want to look into using ssh-agent if you want to try keeping your keys protected with a passphrase.
You seem to be having two different problems:
- impossibility to login to shell (shell access can be disabled on the server) and
- impossibility for the library to open SFTP connection.
In the latter case you need to contact library vendor for assistance - there can be different reasons for the problem.
One thing you can do yourself is check that SFTP subsystem is really configured on the server. If SFTP server is not specified in config, some applications manage to open command channel and try to guess SFTP server location and run it via command channel. Libraries usually don't do this.
Best Answer
iDRAC's embedded SSH server may not have the capability to forward arbitrary ports, even just to itself.
You may have seen an example using a command like this:
Note: this is using a separate "ssh_host" with a full-featured SSH implementation as an intermediary between the client workstation and the DRAC. The idea is that all the traffic for the forwarded ports will be transferred inside the SSH tunnel to the ssh_host, and from there onward as plain TCP connections to the DRAC IP address.
Ideally the ssh_host is in the same network segment as the DRAC, and/or the network between ssh_host and the DRAC is considered secure.