how to contribute to ssh-mitm?

[manfred-kaiser]

I'm interested in contributing to your project. Can you provide a contribution policy for this project?

• Do you prefer to run ssh-mitm in a docker container or should it also run on the host machine?

• What is the reason, why you are working with a patch file and not with the openssh source code?

  • How do you handle conflicting pull request in the patch file?
  • What is the best way to implement a new feature and provide a pull request?

• Is updating Openssh to a more recent version possible or would you like to stay at version 7.5

• Would you like to provide patch files for more recent openssh versions too?

[jtesta]

Do you prefer to run ssh-mitm in a docker container or should it also run on the host machine?

Both should be officially supported soon.

What is the reason, why you are working with a patch file and not with the openssh source code?

The original goal was to allow people to see the changes made in order to transform OpenSSH into SSH MITM. But I agree with your other comments that this has become too unwieldy. I'll be revamping the repository and build process so that all the source code is included.

What is the best way to implement a new feature and provide a pull request?

Until I merge in the OpenSSH code into the repo, I'd wait on submitting PRs. I should have this done in the next few days. After that, please submit a PR against the master branch.

It would be a good idea to file an issue to propose new features before working on a patch to make sure we're all on the same page. It's a shame when people submit PR's to open source projects that never get merged! I think that happens way too often...

Is updating Openssh to a more recent version possible or would you like to stay at version 7.5

A bunch of old algorithms were removed in OpenSSH v7.6, which can impact compatibility with old servers.

Would you like to provide patch files for more recent openssh versions too?

Personally, I wouldn't have time to maintain patches against other OpenSSH versions. What improvements would be gained by doing so from an end-user perspective?

[manfred-kaiser]

Do you prefer to run ssh-mitm in a docker container or should it also run on the host machine?

Both should be officially supported soon.

Which Linux distributions do you want to support?

You should compile ssh-mitm against old libraries, which allows running ssh-mitm on newer distributions. With this approach, you can use a precompiled binary on other linux distributions. For example you have a server without a build environment, but you want to run a mitm server on that machine.

I would recommend CentOS 7. The reason is, that CentOS 7 has old libraries but is still supported until 2024. If you are interested in such an approach, I can prepare the docker container, but the choice is up to you.

What is the reason, why you are working with a patch file and not with the openssh source code?

The original goal was to allow people to see the changes made in order to transform OpenSSH into SSH MITM. But I agree with your other comments that this has become too unwieldy. I'll be revamping the repository and build process so that all the source code is included.

You can add a git submodule, which is based on the original openssh source code: https://github.com/openssh/openssh-portable/tree/V_7_5

Is updating Openssh to a more recent version possible or would you like to stay at version 7.5

A bunch of old algorithms were removed in OpenSSH v7.6, which can impact compatibility with old servers.

Compatibility is one of the reasons, why I'm interested in contributing to your project. My project is based on python paramiko which does not support ssh1 and has some known issues with some clients.

Would you like to provide patch files for more recent openssh versions too?

Personally, I wouldn't have time to maintain patches against other OpenSSH versions. What improvements would be gained by doing so from an end-user perspective?

OpenSSH 8.2 has added 2 factor authentication for public key authentication.

[jtesta]

Which Linux distributions do you want to support?

I'd be nice to support all of them, but time limitations imply that I can only handle Ubuntu and Kali.

You should compile ssh-mitm against old libraries

I checked in OpenSSL 1.0.2u into the master branch. All builds compile and link to it statically regardless of whether its available on the system. This makes building on new & old systems identical and easier to manage.

That said, if you still want CentOS support, I'd be happy to include it (though I may not be able to stay on top of it in the long term...).

You can add a git submodule

I considered using submodules, but considering OpenSSH 7.5p1 and OpenSSL 1.0.2u are both effectively frozen, there won't be a need pull down from upstream. So submodules just seem to make things more complicated without any advantages in this scenario.

OpenSSH 8.2 has added 2 factor authentication for public key authentication.

Public key authentication can't be fully MITM'ed (see #14), so upgrading to OpenSSH 8.2 wouldn't give us any advantages.

After giving it some thought, though, upgrading to a new version of OpenSSH lets us use OpenSSL 1.1.1, which is the only branch supported for security. This is likely to be a huge undertaking. I'll open a separate issue to track this...

[manfred-kaiser]

You should compile ssh-mitm against old libraries

I checked in OpenSSL 1.0.2u into the master branch. All builds compile and link to it statically regardless of whether its available on the system. This makes building on new & old systems identical and easier to manage.

That said, if you still want CentOS support, I'd be happy to include it (though I may not be able to stay on top of it in the long term...).

I'm not talking about to support an addintional distribution. CentOS 7 and AppImage uses the same libraties.
Building an AppImage allows you to run your application on almost any Linux distribution, because when you built an application against old libraries, they are compatible with more recent linux distributions. You have also the option to run an AppImage with the WSL (Windows Subsystem for Linux) or inside a docker container, if this is a requirement.

I have already created a AppImage for my application and I can help you with yours.

This is the reason, why I prefer CentOS 7 over a current Ubuntu Version.

If you want to stay with Ubuntu, you should use Ubuntu Core 18 (Ubuntu 18,04 LTS). This is the recommended version for building snaps (another great way to deploy apps on different linux distributions) Building a Snap is also easier than building an AppImage ;-)

But if you want to stay with docker, I can help you with the docker part :-D

You can add a git submodule

I considered using submodules, but considering OpenSSH 7.5p1 and OpenSSL 1.0.2u are both effectively frozen, there won't be a need pull down from upstream. So submodules just seem to make things more complicated without any advantages in this scenario.

OpenSSH 8.2 has added 2 factor authentication for public key authentication.

Public key authentication can't be fully MITM'ed (see #14), so upgrading to OpenSSH 8.2 wouldn't give us any advantages.

After giving it some thought, though, upgrading to a new version of OpenSSH lets us use OpenSSL 1.1.1, which is the only branch supported for security. This is likely to be a huge undertaking. I'll open a separate issue to track this...

We can talk later about this topic... Perhaps in a few weeks...

[jtesta]

I have already created a AppImage for my application and I can help you with yours. [...] Building a Snap is also easier than building an AppImage ;-)

I'd like to support Snap, but last time I attempted it, I couldn't find good documentation or examples for running daemon processes. Help with this would be appreciated! AppImage doesn't seem to have as large of a userbase as Docker/Snap, but if maintenence is relatively easy, I'd support that too.

But if you want to stay with docker, I can help you with the docker part :-D

Sure, if you have improvements for the Docker image, I'd be happy to accept those as well!