Ssh – Current SSH connection properties (cipher, auth type, timeout, etc)

Quite an interesting problem you've got.

The real solution would be to ask your sysadmin for help first.

If that's not an option, the next best thing is to have pyCharm's libssh or whatever it uses (I did some googling and couldn't figure it out) parse your `~/.ssh/config'.

If that's not possible, you might be able to run your own ssh daemon on the remote host listening on the loopback address and connect to it with a local forward.

To setup an unprivileged ssh daemon (copied from a link on the SF answer):

  $ pwd
  /home/<USER>
  $ mkdir -p etc var/run
  $ cp /etc/sshd_config etc
  $ vi etc/sshd_config
  [Set `Port 2230']
  [Set `HostKey /home/<USER>/etc/ssh_host_rsa_key']
  [Set `UsePrivilegeSeparation no']
  [Set `PidFile /home/<USER>/var/run/sshd.pid']
  [:wq!]
  $ ssh-keygen -t rsa -f /home/<USER>/etc/ssh_host_rsa_key -N ''
  Generating public/private rsa key pair.
  Your identification has been saved in /home/<USER>/etc/ssh_host_rsa_key.
  Your public key has been saved in /home/<USER>/etc/ssh_host_rsa_key.pub.
  The key fingerprint is:
  02:5d:02:5d:e8:2e:c6:b9:4c:d9:93:6c:13:ef:5d:61 hein@vmbert2k8
  $ /usr/sbin/sshd -f /home/<USER>/etc/sshd_config -D

Now forward a local port to it (you will be logging in with 2fa here):

 ssh -L 2230:localhost:2230 example_com_master

And direct pyCharm to localhost:2230. You can also setup keypair auth on your custom sshd.

Note that this is a long shot, and your sysadmin may not appreciate it.

There's a big chance that pyCharm already uses OpenSSH for its ssh implementation. If that's so, adding multiplexing support to pyCharm would be way easier than the workaround I've proposed.

The -cbc algorithms have turned out to be vulnerable to an attack. As a result, up-to-date versions of OpenSSH will now reject those algorithms by default: for now, they are still available if you need them, but as you discovered, you must explicitly enable them.

Initially when the vulnerability was discovered (in late 2008, nearly 10 years ago!) those algorithms were only placed at the tail end of the priority list for the sake of compatibility, but now their deprecation in SSH has reached a phase where those algorithms are disabled by default. According to this question in Cryptography.SE, this deprecation step was already happening in year 2014.

Please consider this a gentle reminder to update your SSH server, if at all possible. (If it's a firmware-based implementation, see if updated firmware is available for your hardware.)