I don't know if this is a Linux Mint problem or a Debian problem. I use Mint as a desktop but I just installed a standard no GUI edition of Debian for my media server. I was going to use the Mint file browser Nemo to connect to the Debian server so it would be easier to copy files to and from but when I enter all the credintials into the connection box and click connect I get this error -> Host key verification failed
I can connect to the Debian server from my Mint desktop just fine through standard SSH.
I've always been able to connect to other systems through Nemo before, any ideas on what's going on? Thanks.

Dani AI

Generated

Short answer: “Host key verification failed” means Nemo’s SFTP/SSH backend refused the server’s SSH host key (either it’s not known locally or it changed). GUI file browsers often don’t prompt the usual SSH fingerprint confirmation, so the simplest fix is to accept the host key from a terminal as the same user Nemo runs under. That will populate your ~/.ssh/known_hosts and allow Nemo to connect.

Practical steps (run on the Mint desktop as the same user who runs Nemo):

ssh user@debian-server-or-ip
# if prompted: type  yes  to accept and add the host key

If SSH warns the host key changed, verify the server’s fingerprint (out of band) and then remove the old entry before reconnecting:

ssh-keygen -R debian-server-or-ip
ssh user@debian-server-or-ip

If using key-based auth and Nemo still fails, GVfs may not see an SSH agent. Either load the key with ssh-add in that session or mount the remote filesystem from the terminal with sshfs:

sshfs user@debian-server:/remote/path /local/mountpoint
# unmount:
fusermount -u /local/mountpoint

Yes, telnet has separate client and server components (the server must run on Debian and a client on the desktop), but telnet/FTP send credentials in clear text and are not recommended except on an isolated LAN. As noted, they are simpler; as suggested, SSHFS or SFTP keeps the connection secure. Also verify host-key fingerprints if a key suddenly changes to rule out misconfiguration or a potential man-in-the-middle.

Recommended Answers

All 3 Replies

Since these systems are both behind your router/firewall, don't bother with SSH but enable telnet and FTP. SSH will require in some cases that your client is registered with the host account (login ID) that you are using, with its public key. Your client needs to use the private key so that the server can validate you. A PITA, but that's the way it works, which is why for local LAN connections I don't bother with SSH usually.

Like rubberman says, SSH can be an annoying method. The problem with trying to rely on SSH connections via GUI applications (like a file explorer) is that SSH can sometimes issue warnings about keys that have changed or otherwise ask for additional steps. In some cases also, the GUI application uses a different user-id, which causes more issues in some setups (like with RSA keys or key-chains).

One alternative is to rely on a simpler (less secure) protocol like telnet or ftp, as rubberman suggests.

Another alternative, if you don't want to compromise on security, is to use something like SSHFS, which allows you to mount a remote file-system through SSH. In that case, you would just mount the remote file-system through the terminal, and then that folder (destination of mount) can be accessed by your GUI file explorer (or any other program) just as a normal folder. And because the mounting is done manually in the terminal, the issues with having a GUI deal with the SSH connection are eliminated.

Are there two versions of telent? Do I need to install telnet server on my Debian server and a telnet client on my desktop?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.