We have a working Perl Program that connects to a Server of a Costumer via Net::SSH2 with an ssh-rsa public and private key pair and automatically downloads some Files that are then proceeded by our System.
Now the customer communicated that they would no longer support ssh-rsa as a host key only ssh-ed25519, rsa-sha2-512 or rsa-sha2-256.
Apparently the Host key is something different compared to the public and private key and when I talked to our Customer they said that is something we have to change on our Side. I have no Idea how to do that. The only thing I found is the remote_hostkey and/or check_hostkey command, with this I figured out that our host key is indeed of the ssh-rsa type.
Is there a way to change that Host Key Algorithms/Type?
As an Alternative, I tried using the Net::SSH::Perl Module. The only one I found that supports more Host Key Algorithms, but it has a lot of other Problems like our public key is not accepted because it is in the OpenSSH Format.
Related
I was trying to do an npm install today and ran into an error that looks like this:
The authenticity of host 'github.com (140.82.114.3)' can't be established <trash due to npm overwriting part of the line>
ECDSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
I have redacted the actual fingerprint but it was hex digits. In another question some of the answers establish that you should verify the authenticity of this key here. But when I go to this page I see keys in a totally different format:
SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8 (RSA)
SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM (ECDSA)
SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU (Ed25519)
I'm assuming since the message I saw mentioned ECDSA I should be trying to compare it to the second value, but beyond this, how do I get this value in the xx:xx:xx... format? You would assume that something important like this would be easy to compare so I'm a bit puzzled as to why there seems to be some excessive friction.
The format you're seeing for your fingerprints is the legacy hex format using MD5. Because MD5 is insecure and no longer suitable for use, since OpenSSH 6.8, fingerprints are printed using SHA-256 and base64. SHA-256 is presently considered secure and is a good choice for a cryptographic hash function.
This probably means that you're using a very old version of OpenSSH, possibly on an unsupported operating system, such as CentOS 6. If your OS is no longer supported, you should upgrade to one receiving security updates for everyone's benefit.
If in the meantime you still need to access GitHub, you can download the actual keys (as well as the fingerprints) from the GitHub API. If you save the ECDSA key into a file, say key, then you can run ssh-keygen -l -f key and it will print the fingerprint for that key in a format you can use.
The exact error is "Could not establish connection to "[server_name]": Remote host key has changed, port forwarding is disabled."
I recently "rolled back" a production environment's update by launching a new instance from a back up. This gives me a new server host key, as expected. Every other SSH connection tool I've used (WinSCP, FileZilla, Text Wrangler, Putty, Terminal, DBeaver, etc) has a notification of the change and lets you confirm the key yourself and verify it is valid (or not).
I cannot find that option in VS Code remote dev tools. It prompts to simply close or retry(same error, obviously). The "More actions" option doesn't give me anything but configuration file options, settings that I believe don't allow me to update the host key, and the documentation which to the best of my knowledge doesn't explain how to update the host key either.
I assume I'm missing something simple somewhere... any help is appreciated.
It was something simple. Found while trying to review the question.
"A supported OpenSSH compatible SSH client must also be installed." as listed in the system requirements of the documentation(linked in question). The key simply needs to be updated in said OpenSSH client before attempting the connection in Visual Studio again.
In this exact case it was as simple as going to [local_path]/.ssh/known_hosts and removing the old entry for the IP address and then attempting the connection again which now allows the verification of the new key.
remove the hostname's key
ssh-keygen -R "hostname"
I tried the prepared VirtualBox stack from bitnami, which I run in bridged mode, but could not pull/push through SSH, I would get prompted with a password request. I have no idea what kind of password this guy wants from me, since none of them worked and I would always get access denied.
I then disabled passwords in the sshd configuration file on the server, since I want to work with keys anyway, defined my own authorized_keys and added public keys for a sample user.
I then got the message:
no supported authentication methods available (server sent: publickey)
I tried calling the repository through HTTP, but this would not enforce any permissions.
I tried setting up my own Virtual Machine with the installer from GitLab, but despite doing everything from tutorials I can't connect to GitLab from outside the VM.
Why and what kind of password does tortoise gitplink want from me? Why can't I use the keys public keys that are placed in the default location on my Windows, and also in a file authorized_keys on the server I am referring to in the sshd configuration file, why does it tell me that there is no authorization method after I disable passphrases?
I have been looking into automating builds using GIT and docker. One of the tools I find useful is ssh-keyscan which adds the result to known_hosts and allows you to bypass the 'fingerprint' prompt when cloning a repository for the first time.
I read a comment which pretty much says that exposing this file is dangerous. I thought keyscan just adds a bunch of public keys to your known_hosts file. Why is this dangerous if anyone sees this - can they not get the exact same public keys using the same tool?
I would have thought that in the link, adding a private ssh key to the docker container would be the dangerous part since this is the part you aren't meant to share.
I'm integrating Bitvise client into my winform app. I am using Bitvise SSH Client command line (stnlc.exe in the app's directory) to do so. My app needs to have multiple connections at the same time.
It works well with some addresses, but some other it doesn't. This is the command that I'm using:
"C:\Program Files (x86)\Bitvise SSH Client\stnlc.exe" -profile="C:\Users\AutoOffer\AutoOffer\bin\Debug\data\sshprofile.bscp" -host=<myhost> -port=22 -user=<username> -pw=<password> -ka=y -proxyFwding=y -proxyListIntf=127.0.0.1 -proxyListPort=<port>
And this is the error I got:
Bitvise SSH Client 6.45 - stnlc - free for individual use only, see EULA
Copyright (C) 2000-2015 by Bitvise Limited.
Connecting to SSH2 server XX.XX.XX.XX:22.
Connection established.
Server version: SSH-2.0-dropbear_0.46
First key exchange started.
ERROR: The SSH2 session has terminated with error.
Reason: Error class: LocalSshDisconn, code: KeyExchangeFailed, message: FlowSshTransport: no mutually supported key exchange algorithm.
Local list: "ecdh-sha2-1.3.132.0.10,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group14-sha1".
Remote list: "diffie-hellman-group1-sha1".
I tried to connect manually by the Bitvise app with GUI and it successfully connected!
I also updated my bitvise version to the latest (6.45).
Local list: "ecdh-sha2-1.3.132.0.10,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group14-sha1".
Remote list: "diffie-hellman-group1-sha1".
So it looks like the remote side just supports diffie-hellman-group1-sha1, which is not supported on your side.
On Bitvise SSH Server Version History I read:
The 1024-bit fixed prime Diffie Hellman key exchange methods, diffie-hellman-group1-sha1 and gssapi-group1-sha1 with Kerberos 5, are now disabled by default, due to doubts about continuing security of Diffie Hellman with a 1024-bit fixed prime. Compatibility with most older clients should be retained via the diffie-hellman-group14-sha1 method, which uses a 2048-bit fixed prime. We recommend migrating older SSH clients to new versions supporting ECDH and ECDSA.
So it looks like you have to modify the settings and allow 1024-bit fixed prime Diffie Hellman key exchange methods. Otherwise you will not be able to connect. As explained it is of course better to change the ssh server settings.
Also, please note that running stnlc as a service is a possibility. With it, the tunnel can be started even without the user having to log on, and can be restarted upon dropping.
Be aware that wrapping and running stnlc as a service (using eg. nssm or winsw) absolutely requires adding the unat=y option to prevent the service from going interactive and failing.