ssh – Upgrade to openssh 8.3 (server) on debian 10 buster

Have a fairly vanilla Debian Buster (10) latest stable.

PCI Scan (sysnet/qualsys/worldpay) shows a PCI Compliance = NO vulnerability identified as CVE-2019-16905

It doesn’t look like it will be fixed for a while. The solution is to upgrade to OpenSSH 8.3.x (latest) which seems fairly straightforward with this

ssh -V
OpenSSH_8.3p1, OpenSSL 1.1.1d  10 Sep 2019

Then restarted ssh via sudo /etc/init.d/ssh restart

However, PCI Scan is still showing OpenSSH_7.9p1 Debian-10+deb10u2 even if ssh -V and sudo ssh -V are both showing OpenSSH_8.3p1, OpenSSL 1.1.1d 10 Sep 2019

  • Doing more debugging yields the following but still not sure what is going on

    type -pa ssh
    /usr/local/bin/ssh <== correct
    /usr/bin/ssh <== OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d 10 Sep 2019
    /bin/ssh <== OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d 10 Sep 201

  • Doing a sudo apt-get remove openssh-server did not really work (had to log back into using backup console from hosting provider)

  • The /etc/init.d/ssh script is showing something

    # /etc/init.d/ssh: start and stop the OpenBSD "secure shell(tm)" daemon

    test -x /usr/sbin/sshd || exit 0
    ( /usr/sbin/sshd -? 2>&1 | grep -q OpenSSH ) 2>/dev/null || exit 0

    umask 022

    if test -f /etc/default/ssh; then
        . /etc/default/ssh

Any insight would be appreciated – thanks!

Generating and Using SSH Keys, Part 3

In previous tutorials in this series, we went over generating SSH keys and how to use them.  We’ll wrap up the series by showing you how to turn off password authentication on your server.

As mentioned in Part 1, SSH key authentication requires both “something you know” (the passphrase) and “something you have” (the SSH private key file).  Some attacker on the other side of the world might guess or brute force your password, or if you’re sloppy you might reuse it on some breached web site.  But none of that matters if the bad guy doesn’t have your SSH private key file.

This doesn’t mean you shouldn’t still use strong passphrases with your SSH private key file.  If for some reason, your client system (such as your home PC or laptop) was compromised, then security rests with this passphrase, so follow normal best practices for strong passphrases.

First, test that SSH key authentication works (see Part 2) so you don’t lock yourself out.

Using your favorite editor (such as vi or nano), edit the /etc/ssh/sshd_config file.  The location is the same on both Debian- and CentOS-based systems.

    sudo vi /etc/ssh/sshd_config

Change these lines as follows:

    PubkeyAuthentication yes
    PasswordAuthentication no

Then restart sshd:

    systemctl restart sshd  

Now try to login.  Here I will use an account that was setup and has not had an ssh key configured:

    $ ssh testuser@myserver
    Permission denied (publickey,gssapi-keyex,gssapi-with-mic). 

Here are the key takeaways from this series:

  • SSH key authentication is based on public key encryption.  The private key should be zealously protected.  On the other hand, the public key does not need to be kept secret.  The public key is what is installed on various servers you wish to connect to.
  • SSH key authentication is superior to passwords because it requires the user to have the SSH key file in his/her possession, not merely know a secret passphrase.
  • You should set a solid passphrase on your SSH private key file in case it is lost/stolen/compromised.
  • The ssh-copy-id utility allows you to very easily setup your SSH key on remote systems if you have a Linux or macOS client.  On Windows, you’ll need to proceed with manual steps.
  • Disabling password authentication on your servers completes the security setup.  Once done, the security of your server is significantly improved.


I’m Andrew, techno polymath and long-time LowEndTalk community Moderator. My technical interests include all things Unix, perl, python, shell scripting, and relational database systems. I enjoy writing technical articles here on LowEndBox to help people get more out of their VPSes.

ssh – Trying to mount remote directory using sshfs: filesystem unresponsive

I’m trying to mount a remote directory using sshfs. I’ve got my .ssh/config set up so that I can ssh into my user on the remote machine like so

ssh wdev

The remote directory in question (let’s suppose it’s located at ~/runtime for the remote user remoteuser) is pretty large (it’s ye old big C++ project, complete with build files and a lot of folders).

From what I’ve read online, I should be able to mount runtime to a folder ~/local-mount (which I’ve already created) like so:

$ sshfs wdev:/home/myuser/runtime ~/local-mount

However when I run this, there’s no output whatsoever. Running sshfs with the -d flag is slightly more informative

$ sshfs -d wdev:/home/myuser/runtime ~/local-mount
FUSE library version: 2.9.7
nullpath_ok: 0
nopath: 0
utime_omit_ok: 0

However at this point the output stops. What’s more, it seems to freeze up other things too. If I open up another shell and try to ls ~/local-mount, it just stays suspended until I interrupt with Ctrl+c. This happens even if I just trigger autocompletion on the directory name from my shell

ls ~/loca<TAB>

nautilus won’t even open. All these symptoms persist until I interrupt the process running sshfs, at which point everything resumes normally. Can someone help me with getting this to run properly?

I should note that while mangling the hostname in the sshfs command will immediately yield an error, I can mangle the remote folder name however I want and I’ll still get the same behavior

For what it’s worth, I’ve attached my ~/.ssh/config below. My connections to wdev actually get forwarded through the proxy wsl, if it’s relevant

# --- init_sd_card generated ---

# Use the key for all hosts
IdentityFile /home/local_user/.ssh/id_rsa

Host wsl
    User remote-user
    Port 2222

Host wdev
    User remote-user
    ProxyCommand ssh wsl -C -W %h:%p

windows – Inconsistent remote network access over SOCKS5 SSH Tunnel

I’m having some issues with SOCKS5 SSH tunnels. Essentially, I’m trying to set them up to be functionally equivalent to a VPN connection. Here’s what I’ve done:

  1. Created SOCKS5 proxy using KiTTY (fork of PuTTY) on localhost port 8888
  2. Set up a SOCKS proxy in Windows Internet options to use that SOCKS proxy for all traffic
  3. Connect using the “Dynamic” Tunnel option in KiTTY.

The actual connection works. Once the proxy is on, if I search “what is my IP address”, for instance, in a browser, it comes back with the remote location’s public IP address.

I tried initiating an RDP connection a local machine on that network, but it timed out. I also found I was not able to ping any remote machines.

The strange thing here is that if I type in the IP address of a web server, like, into the browser, it works. However, if I try pinging that server, the connection times out. So it seems to depend on the protocol being used – HTTP/S works, but ICMP/RDP (and probably anything else) do not.

Based on my troubleshooting, it seems like this might be some kind of network issue. AllowTCPForwarding is On on the remote SSH server (and clearly web-related requests do work). However, all other traffic doesn’t seem to work. What I’m experiencing now seems to be a proxy that only works for web requests in any browser, as opposed to being truly system-wide.

In KiTTY, for Tunneling Destination, I have tried changing Dynamic to both Local and Remote. Neither works. With Local, I can’t load webpages, and with Remote, it says I’m not even connected to a network (proxy misconfiguration). I’ve also tried checking the “Remote ports do the same” option.

What is the actual culprit here? Is it my network settings? Something with the SSH server? A KiTTY configuration? The weird thing here is it’s not that it doesn’t work at all, but that it works halfway. I’m posting this question to SU using the remote IP connection through the SSH tunnel right now.

ssh connecting from macOS to ubuntu refused

I am trying to connect to my PC (ubuntu) from my MacBook using ssh

When I run:

ssh leo@

It connects. However if I try to use my public IP it says

ssh: connect to host port 22: Connection refused

I have tried changing the port to port 2222 and the connection is still refused, only using the public IP address.

ssh – Failed to create new user in Ubuntu 18

How can I create new account in my vps? I want to create a VPN service. if I type adduser in putty it works I can use my created account in VPN app but that account is able to login my VPs as root using the given username and pass but I don’t like that

I already tried this code but don’t work

usermod -s /sbin/nologin username

What happen when I use that code is

  1. I created a new user
  2. It works on VPN app
  3. It works to login as root
  4. When I type usermod -s /sbin/nologin Cannot login as root and in VPN app

I want is

  1. I adduser
  2. The user can use that account in VPN app
  3. But that username cannot be used to login in my vps as root

This code

usermod -s /sbin/nologin username

works on my debian vps but not working on ubuntu

linux – Connect to VGA console via SSH

I have Rock Pi which has HDMI output. Normally I see its console on connected monitor. I can also connect via SSH to this Pi.

But I am looking for a way to SSH into this Pi and switch the view to the VGA output console, so I would operate from my PC on the monitor connected to Pi.

Is it possible, if yes – how? Can I do something like that without screen or tmux?

No direct keyboard or mouse is available for this Pi.

Generating and Using SSH Keys, Part 2

In the previous tutorial, we showed you how to generate an SSH key pair.  In this tutorial, we’ll show you how to use it to login.

In this tutorial:

  • Your ssh key file is called “my-ssh-key”.
  • The server is “” and your user account there is “example”.
  • SSH is running on port 22, the default.

If you were to connect to the server without using a key, you’d be prompted for a password.  We will now configure your account to use SSH key as its preferred authorization.

Note that you don’t need to be root to do this.  Assuming your server is configured with reasonable defaults, this method will work on any Unix-based server (Linux, BSD, etc.). 

We are not specifically setting up ssh keys for root, but these instructions will work for root as well.  Normally you do not want to directly login as root but rather as an unprivileged user, and then either su to root or use sudo.

We can use the very handy OpenSSH utility ssh-copy-id to save a lot of time.  Invoke it as follows.

    $ ssh-copy-id -i ~/.ssh/my-ssh-key
    /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/example/.ssh/"
    The authenticity of host ' (x.x.x.x)' can't be established.
    ECDSA key fingerprint is SHA256:HIi6F+IIkSOLHWUNR8l70WgdNrFlTORdZoZcrD5s4p4.
    Are you sure you want to continue connecting (yes/no/(fingerprint))? yes
    /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
    /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys's password: (enter your password here)
    Number of key(s) added:        1
    Now try logging into the machine, with:   "ssh ''"
    and check to make sure that only the key(s) you wanted were added.

Now let’s try to login:

    $ ssh -i ~/.ssh/my-ssh-key
    Enter passphrase for key '/home/example/.ssh/my-ssh-key': (enter your SSH passphrase)

And you’re good to go!  If you want to see what ssh-copy-id did, take a look at ~/.ssh on your server:

    $ ls -ld ~/.ssh
    drwx------ 2 example example 4096 Apr  2 23:18 /home/example/.ssh
    $ ls -l ~/.ssh/
    total 4
    -rw------- 1 example example 580 Apr  2 23:18 authorized_keys
    $ cat ~/.ssh/authorized_keys 
    ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGPw+oAB0cfuJAaHWaEmXsgJzVm1B4+OP8Qr3ZL9nJf0 ssh key for

ssh-copy-id has done the following:

  1. Created a directory in your home directory called .ssh and set ownership to you
  2. Set permissions on ~/.ssh to mode 700 (drwx——)
  3. Copied your public key to a file called ~/.ssh/authorized_keys
  4. Set the authorized_keys file permissions to mode 600 (rwx——)

Unfortunately, PuTTY does not come with the handy ssh-copy-id utility, so we’ll need to do the server setup manually.

You’ll need your *pastable public* key file handy.  You may recall in the last tutorial we copied the section of puttygen called “Public key for pasting into OpenSSH authorized_keys file” and saved it to a file called “my-ssh-key pastable.txt”.  That is the file you need here.  It’s small enough you can copy/paste the contents.

Login to your server and type the following commands to create the .ssh directory:

    ( ! -d ~/.ssh ) && mkdir ~/.ssh
    chmod 700 ~/.ssh

In that directory, either create or edit a file called authorized_keys (note there is no extension).If it already exists, then you can can edit it and paste the contents of your public key to the end of the file.  If it doesn’t exist, just paste in your public key.  Save the file and quit your editor.

When you’re done, set permissions:

    chmod 600 ~/.ssh/authorized_keys

Now try to login using PuTTY.  We’ll start by setting up an entry for this host.  Scroll down to the SSH section on the left and click Auth.  Then browse for your SSH *private* key:

PuTTY Browse for Private Key

Next click on Connection->Data on the left and enter your username under “Auto-login Username”.  This is so you don’t have to type the username every time.

PuTTY Username

Now go back to Session on the left menu and enter the hostname (or IP) at the top.  Enter a name for this session under “Saved Sessions” and click Save.

PuTTY Save Session

Now go ahead and try logging in.  Answer Yes to the warning about the host key – this simply means it’s not cached in your local list of known hosts.

PuTTY Login 1

PuTTY Login 2

The vast majority of issues logging in with ssh keys are a misconfiguration on the server.  All of the following must be true for SSH key authorization to work:

  1. You must have a directory called .ssh in your home directory (the name can be reconfigured by root but is very rare).
  2. This directory must be owned by you and set to mode 700 (drwx——) so only you can enter it.
  3. You must have a file in this directory called authorized_keys that contains the public key.  Note that if you’re using puttygen.exe, it’s the *pastable* publickey.
  4. This authorized_keys file must be mode 600 (rw——-) so only you can read it.

If you get a Password: prompt instead of being prompted for your SSH keyphrase, check that all of these four conditions are true.

In the next Tutorial, we’ll show you how to significantly harden your server by disabling password authentication so that only SSH key authentication is accepted.


I’m Andrew, techno polymath and long-time LowEndTalk community Moderator. My technical interests include all things Unix, perl, python, shell scripting, and relational database systems. I enjoy writing technical articles here on LowEndBox to help people get more out of their VPSes.

linux – How does the weakness of SHA-1 introduce attack vectors in SSH?

The security branch of my company worries that the use of older versions of OpenSSH (pre-7.4), where the only Key Exchange Algorithm available is SHA-1 is a major security issue. They suggest generating new public/private keypairs for all users in the infrastructure.

As a Linux admin I’m supposed to be making a plan for fixing this issue, but when I try to research it, it seems that there is some mixup between the algorithm used to generate private/public keypairs, and the algorithms used in the connection handshake between two hosts.

As far as I can tell, the SHA-1 hashing algorithm is only used in the key exchange between two hosts, to validate each other, and has nothing to do with generating the public/private keypairs.

It also seems that the demonstrated vulnerability applies to things such as pdf documents, where there are tons of metadata that can be tweaked to try to generate an identical hash without actually generating visible text. I’m not even sure this is possible to implement in the SSH handshake.

My big question is: If our servers are vulnerable because they use SHA-1 in the handshake, what are the worst case scenarios?

  • Can the attacker spoof a known host and capture sensitive information by having an unknowing user log into it?
  • Can the attacker get a hold of login info directly or indirectly?
  • Something else?

Please also correct me if I have misunderstood something, I have found a lot of conflicting information about this!