https://dailystuff.nlDailystuff on the Internet - Posts tagged OpenSSH2024-03-16T09:59:03.806608+00:00ABloghttps://dailystuff.nl/blog/2019/connecting-to-legacy-servers-with-openssh.htmlConnecting to legacy servers with OpenSSH2019-06-25T00:00:00+00:00Hans Spaans<section id="connecting-to-legacy-servers-with-openssh">
<p>Phasing out legacy cryptographic algorithms can always be an interesting endeavor as terminating too early breaks stuff and too late can lead to a compromise. <a class="reference external" href="https://www.openssh.com/">OpenSSH</a> disabled <a class="reference external" href="https://en.wikipedia.org/wiki/Digital_Signature_Algorithm">Digital Signature Algorithm (DSA)</a> with version 7.0 in March 2015 as 5 years earlier it was discovered that DSA was compromised and labeled as insecure. Normally this shouldn’t be a problem with a normal software life cycle, but sometimes you will encounter a legacy box that will not be upgraded as it will break things. Now it will stop new connections from being set up from being upgraded to machines as with <a class="reference external" href="https://en.wikipedia.org/wiki/SSH">SSH</a>.</p>
<div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="go">Their offer: ssh-dss</span>
</pre></div>
</div>
<p>For an incidental connection from the command line, the algorithm can be enabled again to connect with a legacy machine.</p>
<div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="gp">$ </span>ssh<span class="w"> </span>-o<span class="w"> </span><span class="nv">HostKeyAlgorithms</span><span class="o">=</span>+ssh-dss<span class="w"> </span>user@server.example.org
</pre></div>
</div>
<p>For automated processed or when scripts can’t be modified a setting for OpenSSH can also be set in <code class="docutils literal notranslate"><span class="pre">$HOME/.ssh/config</span></code> for the account depending on this option to be set.</p>
<div class="highlight-text notranslate" id="home-ssh-config"><div class="highlight"><pre><span></span> Host server.example.org
HostKeyAlgorithms=+ssh-dss
</pre></div>
</div>
<p>Re-enabling broken algorithms like DSA should only be done for a limited time and scope. In a lot of commercial environments, these algorithms aren’t allowed to be enabled again. Also in most cases, the code to run these obsolete algorithms can be removed in a later version as already is the case with <a class="reference external" href="https://en.wikipedia.org/wiki/Transport_Layer_Security%23SSL_1.0%2C_2.0%2C_and_3.0">SSL 3.0</a> and earlier for example.</p>
</section>
Phasing out legacy cryptographic algorithms can always be an interesting endeavor as terminating too early breaks stuff and too late can lead to a compromise. OpenSSH disabled Digital Signature Algorithm (DSA) with version 7.0 in March 2015 as 5 years earlier it was discovered that DSA was compromised and labeled as insecure. Normally this shouldn’t be a problem with a normal software life cycle, but sometimes you will encounter a legacy box that will not be upgraded as it will break things. Now it will stop new connections from being set up from being upgraded to machines as with SSH.For an incidental connection from the command line, the algorithm can be enabled again to connect with a legacy machine.2019-06-25T00:00:00+00:00https://dailystuff.nl/blog/2017/using-explicit-ssh-authentication-methods.htmlUsing explicit SSH authentication methods2017-05-08T00:00:00+00:00Hans Spaans<section id="using-explicit-ssh-authentication-methods">
<p>For many <a class="reference external" href="https://en.wikipedia.org/wiki/Secure_Shell">Secure Shell (SSH)</a> is a magic sauce to get access to a server and transfer files between servers. But when things go wrong this magic sauce becomes a problem. Let’s start with one example of when things go wrong and how to debug them. First, we start add to option -v to our command to connect to another server to get some basic debug information about the SSH handshake and get to the point the user has to authenticate.</p>
<div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="gp">$ </span>ssh<span class="w"> </span>-v<span class="w"> </span>user@host.example.org
<span class="go">...</span>
<span class="go">debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password</span>
<span class="go">debug1: Next authentication method: password</span>
<span class="go">user@host.example.org's password:</span>
</pre></div>
</div>
<p>Just before the SSH client prompts for the user’s password two interesting debug lines are shown. The first line is about the authentication methods we can use and the next line shows our client selected method <strong>password</strong> as we don’t have any methods configured in our SSH client like <strong>public key</strong>. So we manually disable <strong>publickey</strong> authentication and set the preferred authentication methods to <strong>keyboard-interactive</strong>.</p>
<div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="gp">$ </span>ssh<span class="w"> </span>-v<span class="w"> </span>-o<span class="w"> </span><span class="nv">PreferredAuthentications</span><span class="o">=</span>keyboard-interactive<span class="w"> </span>-o<span class="w"> </span><span class="nv">PubkeyAuthentication</span><span class="o">=</span>no<span class="w"> </span>user@host.example.org
<span class="go">...</span>
<span class="go">debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password</span>
<span class="go">debug1: No more authentication methods to try.</span>
<span class="go">Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).</span>
</pre></div>
</div>
<p>We now get permission denied as our client doesn’t have a matching set of authentication methods. Over a decade ago some commercial SSH servers would require keyboard-interactive as an authentication method as the client must then ask the user to type in the password instead of getting it from a password file as was allowed with the password authentication method. A lot of SSH clients start to ignore this convention, but some enterprise environments still depend on this convention. If we add a password to the list of preferred authentication methods we see the password prompt is offered again.</p>
<div class="highlight-console notranslate"><div class="highlight"><pre><span></span><span class="gp">$ </span>ssh<span class="w"> </span>-o<span class="w"> </span><span class="nv">PreferredAuthentications</span><span class="o">=</span>keyboard-interactive,password<span class="w"> </span>-o<span class="w"> </span><span class="nv">PubkeyAuthentication</span><span class="o">=</span>no<span class="w"> </span>user@host.example.org
<span class="go">user@host.example.org's password:</span>
</pre></div>
</div>
<p>This method can also be used to temporarily disable public-key authentication without changing any SSH configuration to test if the account is still working correctly or the password of the target account is still working.</p>
</section>
For many Secure Shell (SSH) is a magic sauce to get access to a server and transfer files between servers. But when things go wrong this magic sauce becomes a problem. Let’s start with one example of when things go wrong and how to debug them. First, we start add to option -v to our command to connect to another server to get some basic debug information about the SSH handshake and get to the point the user has to authenticate.Just before the SSH client prompts for the user’s password two interesting debug lines are shown. The first line is about the authentication methods we can use and the next line shows our client selected method password as we don’t have any methods configured in our SSH client like public key. So we manually disable publickey authentication and set the preferred authentication methods to keyboard-interactive.2017-05-08T00:00:00+00:00