Let's assume that you have some hardware that still uses weak SSH protocols, and your SSH client won't talk to it...

$ ssh admin@192.168.16.25
Unable to negotiate with 192.168.16.25 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

So the only key exchange the remote is giving us is diffie-hellman-group1-sha1 which is no longer supported by default, but we can force this using the Kex flag like ...

$ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 admin@192.168.16.25
Unable to negotiate with 192.168.16.25 port 22: no matching host key type found. Their offer: ssh-dss

So, a step closer, we've now got to deal with the outdated Host Key ssh-dss, but again we've got a command line argument to fix that so we now try...

$ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -oHostKeyAlgorithms=+ssh-dss admin@192.168.16.25
admin@192.168.16.25's password:

and we're in. Notice the + to 'add' the protocol to SSH just for this session. If your connecting to local equipment over the LAN then this is fairly safe, but I wouldn't recommend it over public networks.