I'm using j2ssh-core-0.2.9.jar to ssh to a Host.
In the logs I can see :
Client Algorithms: [diffie-hellman-group1-sha1]
Server Algorithms: [curve25519-sha256#libssh.org, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffie-hellman-group-
exchange-sha256, diffie-hellman-group-exchange-sha1, diffie-hellman-group14-sha1]
I read the documentation provided on :
https://www.openssh.com/legacy.html
I went to the host to which I'm trying to ssh and executed :
ssh -Q kex
The output is :
diffie-hellman-group1-sha1
diffie-hellman-group14-sha1
diffie-hellman-group-exchange-sha1
diffie-hellman-group-exchange-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
diffie-hellman-group1-sha1
curve25519-sha256#libssh.org
I'm not able to understand how i can resolve this issue, because even though in the logs i can see that the server's key exchange methods do not contain diffie-hellman-group1-sha1 but when i execute the ssh-Q kex command on the host, the output shows that diffie-hellman-group1-sha1 is present.
Please help.
Your SSH client, which is now roughly 10 years old does not support the stronger, more secure algorithms of more modern servers.
I recommend (as the author of the API you are using) that you stop using it and move to a different API. There are plenty more up-to-date open source Java SSH APIs available to you including my own J2SSH Maverick, JSch and I'm sure there will be comments providing the case for others.
Related
According to the Apache MINA sshd official documentation, support for ED25519 must be added by including net.i2p.crypto:eddsa to the classpath.
In my Gradle project, I've done so by writing:
dependencies {
***
// Apache MINA sshd
implementation('org.apache.sshd:apache-sshd:2.9.1') {
exclude group: 'org.apache.sshd', module: 'sshd-netty'
compileClasspath('net.i2p.crypto:eddsa:0.3.0')
}
***
}
I haven't added any changes at the code level, though. For the record, the client code is a copy&paste of some sample code I found online which connects to an SSH server & executes command ll. There's nothing else to it.
However, when trying to connect to a remote machine which only supports ED25519, I still get the error:
Caused by: org.apache.sshd.common.SshException: No more authentication methods available
When inspecting the SSHd log on the server side, I see the client (the Apache MINA sshd client) is still NOT offering ED25519 as part of the KEX negotiation:
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01#openssh.com,ecdsa-sha2-nistp384-cert-v01#openssh.com,ecdsa-sha2-nistp521-cert-v01#openssh.com,ssh-ed25519-ce>
Am I missing any steps? Is there some extra configuration that needs to be done in the client code?
This did the work:
SshClient client = SshClient.setUpDefaultClient();
client.setSignatureFactories(
Arrays.asList(
BuiltinSignatures.ed25519,
BuiltinSignatures.ed25519_cert,
BuiltinSignatures.sk_ssh_ed25519));
client.start();
Vulnerability scan shows that my server (server1821) is currently vulnerable to TLS ROBOT
Server is AIX.
How do I check for this vulnerability and how to fix this?
I checked with my vender and I got the reply as :
Does the scan report which ports are vulnerable? Those applications using TLS protocol with RSA ciphers need to be altered so they no longer use RSA. We need to do this at the application level.
Not sure about this suggestion.
The TLS ROBOT advisory site ((https://robotattack.org/) doesn't have any answers with respect to AIX.
A simple command shows this"
serverl1821 2 % cat /etc/ssh/sshd_config |grep -i rsa
#HostKey /etc/ssh/ssh_host_rsa_key
serverl1821 3 %
Can anyone help me here?
Your application vendor is absolutely correct. First of all you have to ask you security guys, where they found the vulnerability. Not only the server name, but also the port.
Then the problem may be in one of the following component:
OpenSSH
OpenSSL
IBM GSKit
Java
Every of the components requires different tuning to disable RSA ciphers.
To make it more complex every application can come with their own SSL/TLS library and their own set of settings.
The vulnerability may have nothing to do with ssh. You should update GSKit package. This is the package which implement SSL/TLS in AIX. And do not forget to restart web/application server.
I am trying to better understand how ssh does host authentication. I am ssh'ing from a macbook pro (OSX 10.14.6) to several CentOS 8.1 servers. There are several files on the remote CentOS servers in /etc/ssh/ that are used for the host-based authentication (e.g. ssh_host_ed25519_key.pub, ssh_host_dsa_key.pub, ssh_host_rsa_key.pub).
If I look at my macbook's local ~/.ssh/known_hosts, I see entries that use ssh-rsa which corresponds to /etc/ssh/ssh_host_rsa_key.pub. I also see entries for ecdsa-sha2-nistp256 which correspond to /etc/ssh/ssh_host_ecdsa_key.pub.
Question :
When I ssh into my remote server, is there a way for me to force ssh to use a particular algorithm for the host authentication or is this something that I'll have to change by hand in known_hosts? E.g. force it to use ssh_host_ecdsa_key.pub instead of ssh_host_rsa_key.pub.
How does ssh by default decide which algorithm to use for host authentication?
You can use the -o flag to specify options for SSH. One of these options is HostKeyAlgorithms which will control which algorithms your client offers, see: https://man.openbsd.org/ssh.
If you run ssh with the -vv flag you can see the offer that is made by your client. Then the server chooses the first algorithm used by the client that it supports. I would guess that the different support different algorithms.
I'm working on a project that is using goftp to upload to a server, but (thanks to the kind people here) I will use a more secure method.
I plan to use ssh instead and found this ssh client in golang found here.
I have setup an ssh server (freeSSHd) and can successfully connect through PuTTY both locally and on another machine.
I have only changed this part of the client to replace the variables with my own
var (
server = "127.0.0.1:22"
username = "username"
password = clientPassword("password")
)
When I execute the ssh client, ssh.Dial returns an error, and the panic displays this:
"Failed to dial: handshake failed: ssh: no common algorithms"
client, err := ssh.Dial("tcp", "127.0.0.1:22", config)
if err != nil {
panic("Failed to dial: " + err.Error())
}
I am new to golang so I would appreciate any help to point me in the right direction. Thanks in advance.
In the source code for the go.crypto/ssh package, we can see that the supported ciphers are the following:
aes128-ctr
aes192-ctr
aes256-ctr
arcfour128
arcfour256
While freeSSHd supports:
aes128-cbc
aes192-cbc
aes256-cbc
3des-cbc
blowfish-cbc
rijndael128-cbc
rijndael192-cbc
rijndael256-cbc
rijndael-cbc#lysator.liu.se
Because the client and server shares no common cipher, you will get the error message. The reason why CBC mode is not supported in the ssh package is most likely because of a vulnerability, as discussed in this golang-nuts thread.
A solution to your problem might be to try install a different SSH server, such as OpenSSH for Windows.
Though it is insecure you can get go's library to use a cypher supported by freeSSH.
sshConfig.Config.Ciphers = append(sshConfig.Config.Ciphers, "aes128-cbc")
After several days of hammering at this, I have a working CentOS 6.3 system bound to a AD domain running Windows 2008R2. My method is sssd based pam using Kerberos authentication. Directory info is accessed on the domain controller via LDAP. The LDAP bind is also kerberized.
On my client (Mac OS 10.8) I am able to ssh into the CentOS system with all the pieces seemingly clicking right. The Mac gets a ticket and then GSSAPI key exchange takes place followed by gssapi-keyex authentication. So the setup is working but I'm having an issue with slow logins -- about 10 seconds from start to finish. My experience is that kerberized ssh should be instantaneous so something is still not right.
I've monitored the communication between CentOS and the DC using tcpdump and it looks like CentOS gets a response immediately from anything it requests from the DC. The part that it hangs up is actually before it tries to contact the DC at all. It looks like the GSSAPI key exchange is what is slow. So if I look at the ssh connection in debug mode the two points it hangs are
debug1: SSH2_MSG_KEXINIT sent
and
debug1: Doing group exchange
Once it gets to authentication method: gssapi-keyex it flys through. Does anybody have any ideas as to what would cause the key exchange to run slow? Possibly is something not right on my client? On the Mac my ~/.ssh/config file is set as follows:
GSSAPIAuthentication yes
GSSAPIKeyExchange yes
GSSAPIDelegateCredentials yes
GSSAPITrustDNS yes
GSSAPIClientIdentity username#MYDOMAIN.COM
I figured it out, Kerberos makes many many DNS calls and you must have a caching DNS server installed to CentOS if you want to have practical login speeds. So simply install and set up BIND and you'll be good to go.