How to disable ssh for non-root users (allowing ssh only for root user)

Install the package.

  • Wikibooks:OpenSSH
  • Defending against brute force ssh attacks
  • OpenSSH key management: Part 1 on IBM developerWorks, Part 2, Part 3 on funtoo.org
  • Secure Secure Shell

To connect to a server, run:

$ ssh -p port user@server-address
Содержание
  1. The Basics
  2. Configure public key only authentication for ssh
  3. Method 1 – using /etc/ssh/sshd_config file
  4. Method 2 — using /etc/nologin file
  5. Method 3 — using /etc/sshd/sshd.allow file
  6. PermitRootLogin
  7. Force public key authentication
  8. Two-factor authentication and public keys
  9. Protecting against brute force attacks
  10. Limit root login
  11. Connection refused or timeout problem
  12. Is SSH running and listening?
  13. Is the traffic even getting to your computer?
  14. Read from socket failed: connection reset by peer
  15. «Terminal unknown» or «Error opening terminal» error message
  16. subsystem request failed
  17. id_dsa refused by OpenSSH 7.0
  18. No matching key exchange method found by OpenSSH 7.0
  19. tmux/screen session killed when disconnecting from SSH
  20. SSH session stops responding
  21. Slow daemon startup after reboot
  22. Terminate unresponsive SSH connection
  23. WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
  24. Connecting to a remote without the appropriate terminfo entry
  25. Connection through jump host fails with «bash: No such file or directory»
  26. Tips and tricks
  27. Encrypted SOCKS tunnel
  28. Step 1: start the connection
  29. Step 2 (Variant A): configure your browser (or other programs)
  30. Step 2 (Variant B): set up a local TUN interface
  31. Forwarding other ports
  32. Reverse SSH through a relay
  33. Speeding up SSH
  34. Mounting a remote filesystem with SSHFS
  35. Automatically restart SSH tunnels with systemd
  36. Autossh — automatically restarts SSH sessions and tunnels
  37. Run autossh automatically at boot via systemd
  38. Alternative service should SSH daemon fail
  39. Terminal background color based on host
  40. Network specific configuration
  41. Private networks hostkeys verification
  42. Run command at login
  43. Generating new keys

The client can be configured to store common options and hosts. All options can be declared globally or restricted to specific hosts. For example:

~/.ssh/config
# global options
User user

# host-specific options
Host myserver
    Hostname server-address
    Port     port
$ ssh -p port user@server-address
$ ssh myserver

Some options do not have command line switch equivalents, but you can specify configuration options on the command line with -o. For example -oKexAlgorithms=+diffie-hellman-group1-sha1.

OpenSSH (OpenBSD Secure Shell) is a set of computer programs providing encrypted communication sessions over a computer network using the Secure Shell (SSH) protocol. It was created as an open source alternative to the proprietary Secure Shell software suite offered by SSH Communications Security. OpenSSH is developed as part of the OpenBSD project, which is led by Theo de Raadt.

OpenSSH is occasionally confused with the similarly-named OpenSSL; however, the projects have different purposes and are developed by different teams, the similar name is drawn only from similar goals.

The Basics

SSH server has multiple ways of authenticating a client connecting to it. The most popular method is password-based authentication as it is the easiest one, however it is not so secure. Passwords are exchanged with secure mechanisms, however, due to ease of use they are generally not complex or long. This enables the attacker to break the password using brute-force or dictionary attacks. In such scenarios, the SSH keys can provide a secure and reliable means of authentication for clients.

Configure public key only authentication for ssh

1. As root, edit the sshd daemon configuration file (/etc/ssh/sshd_config).

PermitRootLogin without-password
PubkeyAuthentication yes

Allow only key-based ssh login in the root account by setting the directive PermitRootLogin value as without-password as shown above.

3. Verify the syntax of the configuration file sshd_config is correct before restarting sshd deamon.

The above command should return nothing. This means the config file is syntactically correct and you are sure of restarting sshd daemon without any issue.

4. Restart the sshd daemon:


Method 1 – using /etc/ssh/sshd_config file

# vi /etc/ssh/sshd_config
AllowUsers root

Note: keywords are case-insensitive and arguments are case-sensitive as well.

Now restart sshd service:

# service sshd restart
Stopping sshd:                                             [  OK  ]
Starting sshd:                                             [  OK  ]
# ssh test@host1
test@host1's password: 
Permission denied, please try again.
test@host1's password: 
Permission denied, please try again.
test@host1's password: 
Permission denied (publickey,gssapi-with-mic,password).
# ssh root@host1
root@host1's password: 
Last login: Wed Sep 13 10:47:14 2017 from 10.10.10.10
[root@host1 ~]#

Method 2 — using /etc/nologin file

1. Create a file /etc/nologin on the remote host.

# touch /etc/nologin
# ls -lrt /etc/nologin
-rw-r--r-- 1 root root 0 Sep 13 13:23 /etc/nologin

Make sure the below line is in the file /etc/pam.d/sshd:

account    required     pam_nologin.so
Note: backup the file /etc/pam.d/sshd before modifying it.

Then restart sshd service:

# service sshd restart
Stopping sshd:                                             [  OK  ]
Starting sshd:                                             [  OK  ]
# ssh test@host1
test@host1's password: 
Connection closed by 192.168.10.10

Method 3 — using /etc/sshd/sshd.allow file

# cat /etc/sshd/sshd.allow 
root

2. Replace auth line as below in file /etc/pam.d/sshd:

auth required pam_listfile.so item=user sense=allow file=/etc/sshd/sshd.allow onerr=fail

3. Restart sshd service once you are done with all above changes.

# service sshd restart
Stopping sshd:                                             [  OK  ]
Starting sshd:                                             [  OK  ]
# ssh test@host1
test@host1's password: 
Permission denied, please try again.
test@host1's password: 
Permission denied, please try again.
test@host1's password: 
Permission denied (publickey,gssapi-with-mic,password).
# ssh root@host1
ssh root@host1's password: 
Last login: Wed Sep 13 14:53:47 2017 from 10.10.10.10
[root@host1 ~]#

I just installed Ubuntu 14.04 on my server and I was setting up all my config files when I came across this in my sshd_config file:

# Authentication:
LoginGraceTime 120
PermitRootLogin without-password
StrictModes yes

This made me very worried. I thought that it was possible that someone could be logging into my server as root without a password.

I tried connecting to my server as root via:

johns-mbp:~ john$ ssh root@192.168.1.48
The authenticity of host '192.168.1.48 (192.168.1.48)' can't be established.
RSA key fingerprint is 40:7e:28:f1:a8:36:28:da:eb:6f:d2:d0:3f:4b:4b:fe.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.48' (RSA) to the list of known hosts.
root@192.168.1.48's password:  

I entered a blank password and it didn’t let me in, which was a relief. So my question is: what does without password mean and why is this a default in Ubuntu 14.04?

asked Apr 18, 2014 at 1:12

John's user avatar

3 gold badges14 silver badges17 bronze badges

From the man page:

PermitRootLogin

Specifies whether root can log in using ssh(1). The argument must be “yes”, “without-password”, “forced-commands-only”, or «no”. The default is “yes”.

If this option is set to prohibit-password (or its deprecated alias, without-password), password and keyboard-interactive authentication are disabled for root.

If this option is set to “forced-commands-only”, root login with public key authentication will be allowed, but only if the command option has been specified (which may be useful for taking remote backups even if root login is normally not allowed). All other authentication methods are disabled for root.

If this option is set to “no”, root is not allowed to log in.

Thus, prohibit-password allows root login only with public key authentication. This is often used with shell scripts and automated tasks.

Pablo Bianchi's user avatar

answered Apr 18, 2014 at 1:26

Florian Diesch's user avatar

Florian Diesch

17 gold badges224 silver badges214 bronze badges

Actually this setting does pretty much nothing if you are using PAM authentication. At the bottom of the sshd_config configuration file you will find:

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.

The default setting on Ubuntu is to use PAM authentication:

UsePAM yes

answered Nov 15, 2014 at 17:34

Atari911's user avatar

4 silver badges6 bronze badges

In newer versions of sshd (OpenSSH 7.0 and above, released on 2015-08-11) «without-password» has been changed to «prohibit-password«.

Both version work, probably best to use «prohibit-password» if you can: it explains itself better.

  • sshd_config(5): PermitRootLogin now accepts an argument of ‘prohibit-password’ as a less-ambiguous synonym of ‘without-password’.

Pablo Bianchi's user avatar

answered Mar 22, 2018 at 23:12

teknopaul's user avatar

15 silver badges17 bronze badges

Note that there are legitimate reasons for logging in via root (but using cryptographic keys and never a password). A typical example is remotely syncing two servers (to have one of them being used as fail-over). Because the structure must be identical, often a root password is required.

Here is an example using unison for the synchronisation.

Pablo Bianchi's user avatar

answered Jan 17, 2015 at 20:26

Gwyneth Llewelyn's user avatar

sshd is the OpenSSH server daemon, configured with /etc/ssh/sshd_config and managed by sshd.service. Whenever changing the configuration, use sshd in test mode before restarting the service to ensure it will be able to start cleanly. Valid configurations produce no output.

# sshd -t

AllowUsers    user1 user2

To allow access only for some groups:

AllowGroups   group1 group2

To add a nice welcome message (e.g. from the /etc/issue file), configure the Banner option:

Banner /etc/issue
HostKey /etc/ssh/ssh_host_rsa_key

If the server is to be exposed to the WAN, it is recommended to change the default port from 22 to a random higher one like this:

Port 39901
  • To help select an alternative port that is not already assigned to a common service, review the list of TCP and UDP port numbers. You can also find port information locally in /etc/services. A port change from default port 22 will reduce the number of log entries caused by automated authentication attempts but will not eliminate them. See Port knocking for related information.
  • It is recommended to disable password logins entirely. This will greatly increase security, see #Force public key authentication for more information. See #Protection for more recommend security methods.
  • OpenSSH can listen to multiple ports simply by having multiple Port port_number lines in the configuration file.
  • New (or missing) host key pairs can be generated by removing the pair(s) that you want to replace from /etc/ssh and running ssh-keygen -A as root.

Warning: If you continue using sshd.socket, be aware of its issues:

  • sshd.socket unit may fail (e.g. due to out-of-memory situation) and Restart=always cannot be specified on socket units. See systemd issue 11553.
  • Using socket activation can result in denial of service, as too many connections can cause refusal to further activate the service. See FS#62248.

offers an automated analysis of server and client configuration. Several other good guides and tools are available on the topic, for example:

Force public key authentication

/etc/ssh/sshd_config
PasswordAuthentication no
AuthenticationMethods publickey

Two-factor authentication and public keys

SSH can be set up to require multiple ways of authentication; you can tell which authentication methods are required using the AuthenticationMethods option. This enables you to use public keys as well as a two-factor authorization.

See Google Authenticator to set up Google Authenticator.

For Duo, install AUR which will supply the pam_duo.so module. Read the Duo Unix documentation for instructions on how to setup the necessary Duo credentials (Integration Key, Secret Key, API Hostname).

/etc/ssh/sshd_config
KbdInteractiveAuthentication yes
AuthenticationMethods publickey keyboard-interactive:pam
/etc/ssh/sshd_config
KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactive:pam

With required pubkey and pam authentication, you may wish to disable the password requirement:

/etc/pam.d/sshd
auth      required  pam_securetty.so     #disable remote root
#Require google authenticator
auth      required  pam_google_authenticator.so
#But not password
#auth      include   system-remote-login
account   include   system-remote-login
password  include   system-remote-login
session   include   system-remote-login

Protecting against brute force attacks

See ufw#Rate limiting with ufw or Simple stateful firewall#Bruteforce attacks for iptables.

  • Only allow incoming SSH connections from trusted locations
  • Use fail2ban or sshguard to automatically block IP addresses that fail password authentication too many times.
  • Use pam_shield to block IP addresses that perform too many login attempts within a certain period of time. In contrast to fail2ban or sshguard, this program does not take login success or failure into account.

Limit root login

Tango-view-refresh-red.pngThis article or section is out of date.Tango-view-refresh-red.png

Reason: Root login has been disabled by default upstream in the current version. Unclear to me what parts of this section and subsections are redundant. (Discuss in Talk:OpenSSH)

Sudo selectively provides root rights for actions requiring these without requiring authenticating against the root account. This allows locking the root account against access via SSH and potentially functions as a security measure against brute force attacks, since now an attacker must guess the account name in addition to the password.

/etc/ssh/sshd_config
PermitRootLogin no

Next, restart the SSH daemon.

command="/usr/lib/rsync/rrsync -ro /" ssh-rsa …

This will allow any login with this specific key only to execute the command specified between the quotes.

PermitRootLogin forced-commands-only

This setting will not only restrict the commands which root may execute via SSH, but it will also disable the use of passwords, forcing use of public key authentication for the root account.

A slightly less restrictive alternative will allow any command for root, but makes brute force attacks infeasible by enforcing public key authentication. For this option, set:

PermitRootLogin prohibit-password

$ chmod 400 ~/.ssh/authorized_keys

Tip: It is recommended to log changes to any authorized_keys file via e.g auditd.

The solution for this is to use SSH certificates that provide automatic verification of public key identities through a chain of trust that scales significantly better than the default trust-on-first-use approach of SSH. SSH certificates are basically nothing else then normal public SSH keys, but with an additional signature from a trusted certificate authority that verifies the key identity.

Create a host certificate authority key for your infrastructure
$ ssh-keygen -t ed25519 -f ~/.ssh/ca_host_key -C 'Host certificate authority for *.example.com'

The private certificate authority key should be stored securely, ideally on a smartcard or hardware token that prevents key extraction like the Nitrokey or YubiKey.

Sign a server’s public SSH host key

Copy the public server key to your local system containing the private certificate authority key to sign it:

$ ssh-keygen -h -s ~/.ssh/ca_key -I certLabel -n server01.example.com ./ssh_host_ed25519_key.pub
Move the new certificate and configure sshd to use it

The generated certificate ssh_host_ed25519_key-cert.pub should be copied to the server at /etc/ssh/.

/etc/ssh/sshd_config
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub
Configure all clients to trust the certificate authority
~/.ssh/known_hosts
@cert-authority  *.example.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKL8gB/pjuff005YNazwMCqJpgsXAbQ3r4VStd/CRKwU Host certificate authority for *.example.com

Warning: When a server does not provide a certificate for identification, public key authentication is used as fallback by default.

Certificate deployment automation

Automated deployment of SSH certificates can be provided by a number of open source tools. Popular examples are:

$ cat id_rsa.pub >> ~/.ssh/authorized_keys
$ ssh -vvv 'mar@192.168.1.2'
OpenSSH_6.6.1, OpenSSL 1.0.1h 5 Jun 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.2 [192.168.1.2] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/mar/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/mar/.ssh/id_rsa type 1
debug1: identity file /home/mar/.ssh/id_rsa-cert type -1
debug1: identity file /home/mar/.ssh/id_dsa type -1
debug1: identity file /home/mar/.ssh/id_dsa-cert type -1
debug1: identity file /home/mar/.ssh/id_ecdsa type -1
debug1: identity file /home/mar/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/mar/.ssh/id_ed25519 type -1
debug1: identity file /home/mar/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "192.168.1.2" from file "/home/mar/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/mar/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: setup hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: setup hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 1541/3072
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 91:00:8d:42:51:14:6b:0a:9f:e4:0e:fc:e1:51:f5:07
debug3: load_hostkeys: loading entries for host "192.168.1.2" from file "/home/mar/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/mar/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug1: Host '192.168.1.2' is known and matches the RSA host key.
debug1: Found key in /home/mar/.ssh/known_hosts:1
debug2: bits set: 1580/3072
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/mar/.ssh/id_rsa (0x7fbc63bf4ef0),
debug2: key: /home/mar/.ssh/id_rsa (0x7fbc63befbc0),
debug2: key: /home/mar/.ssh/id_dsa ((nil)),
debug2: key: /home/mar/.ssh/id_ecdsa ((nil)),
debug2: key: /home/mar/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/mar/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Offering RSA public key: /home/mar/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Trying private key: /home/mar/.ssh/id_dsa
debug3: no such identity: /home/mar/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/mar/.ssh/id_ecdsa
debug3: no such identity: /home/mar/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/mar/.ssh/id_ed25519
debug3: no such identity: /home/mar/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
 .ssh]$ ls -l
celkem 12
-rw------- 1 mar mar 1766 11. čen 09.37 id_rsa
-rw------- 1 mar mar  405 11. čen 09.37 id_rsa.pub
-rw------- 1 mar mar  393 11. čen 09.44 known_hosts

Check these simple issues before you look any further.

  1. The configuration directory ~/.ssh, its contents should be accessible only by the user (check this on both the client and the server), and the user’s home directory should only be writable by the user:
    $ chmod go-w ~
    $ chmod 700 ~/.ssh
    $ chmod 600 ~/.ssh/*
    $ chown -R $USER ~/.ssh
    
  2. Check that the client’s public key (e.g. id_rsa.pub) is in ~/.ssh/authorized_keys on the server.
  3. Check that you did not limit SSH access with AllowUsers or AllowGroups in the server config.
  4. Check if the user has set a password. Sometimes new users who have not yet logged in to the server do not have a password.
  5. Append LogLevel DEBUG to /etc/ssh/sshd_config.
  6. Run journalctl -xe as root for possible (error) messages.
  7. Restart sshd and logout/login on both client and server.

Connection refused or timeout problem

If you are behind a NAT mode/router (which is likely unless you are on a VPS or publicly addressed host), make sure that your router is forwarding incoming ssh connections to your machine. Find the server’s internal IP address with $ ip addr and set up your router to forward TCP on your SSH port to that IP. portforward.com can help with that.

Is SSH running and listening?

$ ss --tcp --listening

If the above command do not show the system is listening to the port ssh, then SSH is not running: check the journal for errors etc.

# iptables -nvL
# iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT

Is the traffic even getting to your computer?

Start a traffic dump on the computer you are having problems with:

# tcpdump -lnn -i any port ssh and tcp-syn

Note: Try this step if you know you are not running any firewalls and you know you have configured the router for DMZ or have forwarded the port to your computer and it still does not work. Here you will find diagnostic steps and a possible solution.

If you get an error message comparable to this:

ssh: connect to host www.inet.hr port 22: Connection refused

However, if you get an error message comparable to this:

ssh: connect to host 111.222.333.444 port 22: Operation timed out 

Install either or Wireshark with the package.

# tcpdump -ni interface "port 22"
$ tshark -f "tcp port 22" -i interface
Port 22
Port 1234

Also make sure that other «Port» configuration lines in the file are commented out. Just commenting «Port 22» and putting «Port 1234» will not solve the issue because then sshd will only listen on port 1234. Use both lines to run the SSH server on both ports.

Restart the server sshd.service and you are almost done. You still have to configure your client(s) to use the other port instead of the default port. There are numerous solutions to that problem, but let us cover two of them here.

Read from socket failed: connection reset by peer

If that does not work, it could be that the list of ciphers is too long. Set the Ciphers option to a shorter list (fewer than 80 characters should be enough). Similarly, you can also try shortening the list of MACs.

See also the discussion on the openssh bug forum.

«Terminal unknown» or «Error opening terminal» error message

If you receive the above errors upon logging in, this means the server does not recognize your terminal. Ncurses applications like nano may fail with the message «Error opening terminal».

The correct solution is to install the client terminal’s terminfo file on the server. This tells console programs on the server how to correctly interact with your terminal. You can get info about current terminfo using $ infocmp and then find out which package owns it.

If you cannot install it normally, you can copy your terminfo to your home directory on the server:

$ ssh myserver mkdir -p  ~/.terminfo/${TERM:0:1}
$ scp /usr/share/terminfo/${TERM:0:1}/$TERM myserver:~/.terminfo/${TERM:0:1}/

After logging in and out from the server the problem should be fixed.

Note: This should only be used as a last resort.

Alternatively, you can simply set TERM=xterm in your environment on the server (e.g. in .bash_profile). This will silence the error and allow ncurses applications to run again, but you may experience strange behavior and graphical glitches unless your terminal’s control sequences exactly match xterm’s.

If you are seeing this error in your sshd logs, make sure you have set a valid HostKey

HostKey /etc/ssh/ssh_host_rsa_key

subsystem request failed

Since OpenSSH 8.8, scp uses SFTP as the default protocol for data transfers by requesting the subsystem named sftp. If you run scp in verbose mode, scp -v, you can determine which subsystem your client is using (e.g. Sending subsystem: <subsystem-name>). Errors such as subsystem request failed on channel 0 may be fixed by configuring the server’s Subsystem settings: . The server configuration should resemble the example below.

/etc/ssh/sshd_config
...
Subsystem subsystem-name /path/to/subsystem-executable
...

id_dsa refused by OpenSSH 7.0

OpenSSH 7.0 deprecated DSA public keys for security reasons. If you absolutely must enable them, set the configuration option PubkeyAcceptedKeyTypes +ssh-dss (https://www.openssh.com/legacy.html does not mention this).

No matching key exchange method found by OpenSSH 7.0

OpenSSH 7.0 deprecated the diffie-hellman-group1-sha1 key algorithm because it is weak and within theoretical range of the so-called Logjam attack (see https://www.openssh.com/legacy.html). If the key algorithm is needed for a particular host, ssh will produce an error message like this:

Unable to negotiate with 127.0.0.1: no matching key exchange method found.
Their offer: diffie-hellman-group1-sha1

The best resolution for these failures is to upgrade/configure the server to not use deprecated algorithms. If that is not possible, you can force the client to reenable the algorithm with the client option KexAlgorithms +diffie-hellman-group1-sha1.

tmux/screen session killed when disconnecting from SSH

The KillMode=process setting may also be useful with the classic ssh.service, as it avoids killing the SSH session process or the or processes when the server gets stopped or restarted.

SSH session stops responding

SSH responds to flow control commands XON and XOFF. It will freeze/hang/stop responding when you hit Ctrl+s. Use Ctrl+q to resume your session.

If you attempt to create a connection which results in a Broken pipe response for packet_write_wait, you should reattempt the connection in debug mode and see if the output ends in error:

debug3: send packet: type 1
packet_write_wait: Connection to A.B.C.D port 22: Broken pipe
/etc/ssh/ssh_config
Host *
    IPQoS reliability

The reliability (0x04) type-of-service should resolve the issue, as well as 0x00 and throughput (0x08).

Slow daemon startup after reboot

Terminate unresponsive SSH connection

If a client session is no longer responding and cannot be terminated by instructing the running program (e.g. shell), you can still terminate the session by pressing Enter, ~ and . one after another in that order.

The ~ is a pseudo-terminal escape character (see ssh(1) § ESCAPE CHARACTERS), which can be added multiple times depending on the client session to terminate. For example, if you connected from A to B and then from B to C and the session from B to C freezes, you can terminate it by pressing Enter and typing ~~., which will leave you in a working session on B.

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

If the client warns that the key of an ssh server has changed, you should verify that the newly offered key really belongs to the server operator. Then remove the old key from the known_hosts file with ssh-keygen -R $SSH_HOST and accept the new key as if it was a new server.

Connecting to a remote without the appropriate terminfo entry

When connecting to hosts that do not have a terminfo entry for your terminal, for example, when using a terminal emulator whose terminfo entry is not shipped with (e.g. kitty and rxvt-unicode), or when connecting to hosts with a limited terminfo database (e.g. systems running OpenWrt), various issues will occur with software that relies on .

A proper solution is to place the appropriate terminfo entry on the host. If that is not feasible, an alternative is to set TERM to a value that is both supported by the remote host and compatible with the terminal.

Since OpenSSH 8.7, a custom TERM environment variable can be passed to remote hosts with a simple configuration snippet:

~/.ssh/config
Host example.com
  SetEnv TERM=xterm-256color

Connection through jump host fails with «bash: No such file or directory»

If you do not have the SHELL environment variable set to a full valid path (on the jump server), connection will fail with an error message simmilar to this one:

bash: No such file or directory
kex_exchange_identification: Connection closed by remote host
Connection closed by UNKNOWN port 65535

You can simply solve this by setting your SHELL to a full path name of a shell that will also be valid on the jump server or by setting a specific SHELL variable for each server in your ~/.ssh/config file.

Tips and tricks

Encrypted SOCKS tunnel

Tango-edit-clear.pngThis article or section needs language, wiki syntax or style improvements. See Help:Style for reference.Tango-edit-clear.png

Reason: Written like a blog post. (Discuss in Talk:OpenSSH)

Step 1: start the connection

You only have to execute this single command to start the connection:

$ ssh -TND 4711 user@host

It is nice to add the verbose (-v) flag, because then you can verify that it is actually connected from that output.

Step 2 (Variant A): configure your browser (or other programs)

The above step is useful only in combination with a web browser or another program that uses this newly created SOCKS tunnel. Since SSH currently supports both SOCKS v4 and SOCKS v5, you can use either of them.

  • For Firefox: At Preferences > General navigates to the bottom of the page and click Settings…, which is to the right of the Network Settings title. Next, within the new semi window, check the Manual proxy configuration option and enter localhost in the SOCKS host text field, and the port number in the Port text field (4711 in the example above) next to it.
Firefox does not automatically make DNS requests through the socks tunnel. This potential privacy concern can be mitigated by scrolling further down, checking in the Proxy DNS when using SOCKS v5. Obviously, this will only work if you chooses SOCKS v5 rather than v4.
Restart Firefox to activate these settings.
  • For Chromium: You can set the SOCKS settings as environment variables or as command line options. I recommend to add one of the following functions to your .bashrc:
function secure_chromium {
    port=4711
    export SOCKS_SERVER=localhost:$port
    export SOCKS_VERSION=5
    chromium &
    exit
}
function secure_chromium {
    port=4711
    chromium --proxy-server="socks://localhost:$port" &
    exit
}

Now open a terminal and just do:

$ secure_chromium

Enjoy your secure tunnel!

Step 2 (Variant B): set up a local TUN interface

This variant is slightly more involved upfront but results in you not having to manually configure every single application one by one to use the SOCKS proxy. It involves setting up a local TUN interface and routing traffic through it.

See VPN over SSH#Set up badvpn and tunnel interface.

X11 forwarding is a mechanism that allows graphical interfaces of X11 programs running on a remote system to be displayed on a local client machine. For X11 forwarding the remote host does not need to have a full X11 system installed; however, it needs at least to have xauth installed. xauth is a utility that maintains Xauthority configurations used by server and client for authentication of X11 session (source).

  • install the packages
  • in /etc/ssh/sshd_config:
    • set X11Forwarding to yes
    • verify that AllowTcpForwarding and X11UseLocalhost options are set to yes, and that X11DisplayOffset is set to 10 (those are the default values if nothing has been changed, see )
  • then restart the sshd daemon.
  • install the package
  • enable the ForwardX11 option by either specifying the -X switch on the command line for opportunistic connections, or by setting ForwardX11 to yes in the client’s configuration.

Tip: You can enable the ForwardX11Trusted option (-Y switch on the command line) if GUI is drawing badly or you receive errors; this will prevent X11 forwardings from being subjected to the X11 SECURITY extension controls. Be sure you have read the warning at the beginning of this section if you do so.

Log on to the remote machine normally, specifying the -X switch if ForwardX11 was not enabled in the client’s configuration file:

$ ssh -X user@host

If you receive errors trying to run graphical applications, try ForwardX11Trusted instead:

$ ssh -Y user@host

Given the output X11 forwarding request failed, redo the setup for your remote machine. Once the X11 forwarding request succeeds, you can start any X program on the remote server, and it will be forwarded to your local session:

$ xclock

Error output containing Can't open display indicates that DISPLAY is improperly set.

$ firefox --no-remote

If you get «X11 forwarding request failed on channel 0» when you connect (and the server /var/log/errors.log shows «Failed to allocate internet-domain X11 display socket»), make sure package is installed. If its installation is not working, try to either:

  • enable the AddressFamily any option in sshd_config on the server, or
  • set the AddressFamily option in sshd_config on the server to inet.

Setting it to inet may fix problems with Ubuntu clients on IPv4.

Tip: Here are some useful links for troubleshooting X11 Forwarding issues.

Forwarding other ports

In addition to SSH’s built-in support for X11, it can also be used to securely tunnel any TCP connection, by use of local forwarding or remote forwarding.

Local forwarding opens a port on the local machine, connections to which will be forwarded to the remote host and from there on to a given destination. Very often, the forwarding destination will be the same as the remote host, thus providing a secure shell and, e.g. a secure VNC connection, to the same machine. Local forwarding is accomplished by means of the -L switch and it is accompanying forwarding specification in the form of <tunnel port>:<destination address>:<destination port>.

$ ssh -L 1000:mail.google.com:25 192.168.0.100

will use SSH to login to and open a shell on 192.168.0.100, and will also create a tunnel from the local machine’s TCP port 1000 to mail.google.com on port 25. Once established, connections to localhost:1000 will connect to the Gmail SMTP port. To Google, it will appear that any such connection (though not necessarily the data conveyed over the connection) originated from 192.168.0.100, and such data will be secure between the local machine and 192.168.0.100, but not between 192.168.0.100 and Google, unless other measures are taken.

$ ssh -L 2000:192.168.0.100:6001 192.168.0.100

will allow connections to localhost:2000 which will be transparently sent to the remote host on port 6001. The preceding example is useful for VNC connections using the vncserver utility—part of the tightvnc package—which, though very useful, is explicit about its lack of security.

Remote forwarding allows the remote host to connect to an arbitrary host via the SSH tunnel and the local machine, providing a functional reversal of local forwarding, and is useful for situations where, e.g., the remote host has limited connectivity due to firewalling. It is enabled with the -R switch and a forwarding specification in the form of <tunnel port>:<destination address>:<destination port>.

$ ssh -R 3000:irc.libera.chat:6667 192.168.0.200

$ ssh -A -t -l user1 bastion1 \
  ssh -A -t -l user2 intermediate2 \
  ssh -A -t -l user3 target

This can be automated with the ProxyCommand option:

$ ssh -o ProxyCommand="ssh -W %h:%p bastion.example.org" targetserver.example.org

An easier and more secure way to do this is using the ProxyJump option with the -J flag:

$ ssh -J user1@bastion1,user2@intermediate2 user3@target

An equivalent of the -J flag in the configuration file is the ProxyJump option; see for details.

Reverse SSH through a relay

Tango-edit-clear.pngThis article or section needs language, wiki syntax or style improvements. See Help:Style for reference.Tango-edit-clear.png

ssh -R 2222:localhost:22 -N user2@relay

Which can also be automated with a startup script, systemd service or autossh.

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

At the client side, the connection is established with:

ssh -t user2@relay ssh user3@localhost -p 2222
command="ssh user3@localhost -p 2222" ssh-rsa KEY2 user1@client

In this case the connection is established with:

ssh user2@relay

Note that SCP’s autocomplete function in client’s terminal is not working and even the SCP transfers themselves are not working under some configurations.

/etc/ssh/sshd_config
Port 22
Port 443

However, it is likely that port 443 is already in use by a web server serving HTTPS content, in which case it is possible to use a multiplexer, such as , which listens on the multiplexed port and can intelligently forward packets to many services.

Speeding up SSH

There are several client configuration options which can speed up connections either globally or for specific hosts. See for full descriptions of these options.

  • Use a faster cipher: on modern CPUs with AESNI instructions, aes128-gcm@openssh.com and aes256-gcm@openssh.com should offer significantly better performance over openssh’s default preferred cipher, usually chacha20-poly1305@openssh.com. Cipher can be selected with the -c flag. For a permanent effect, put Ciphers option in your ~/.ssh/config with ciphers in new preferred order, e.g.:
    Ciphers aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
  • Enable or disable compression: compression can increase speed on slow connections; it is enabled with the Compression yes option or the -C flag. However, the compression algorithm used is the relatively slow which becomes the bottleneck on fast networks. In order to speed up the connection, one should use the Compression no option on local or fast networks.
  • Connection sharing: you can make all sessions to the same host share a single connection using these options:
    ControlMaster auto
    ControlPersist yes
    ControlPath ~/.ssh/sockets/socket-%r@%h:%p
    
where ~/.ssh/sockets can be any directory not writable by other users.
  • ControlPersist specifies how long the master should wait in the background for new clients after the initial client connection has been closed. Possible values are either:
    • no to close the connection immediately after the last client disconnects,
    • a time in seconds,
    • yes to wait forever, the connection will never be closed automatically.
  • Login time can be shortened by bypassing IPv6 lookup using the AddressFamily inet option or -4 flag.
  • Last, if you intend to use SSH for SFTP or SCP, High Performance SSH/SCP can significantly increase throughput by dynamically raising the SSH buffer sizes. Install the package AUR to use a patched version of OpenSSH with this enhancement.

Mounting a remote filesystem with SSHFS

Please refer to the SSHFS article to mount a SSH-accessible remote system to a local directory, so you will be able to do any operation on the mounted files with any tool (copy, rename, edit with vim, etc.). sshfs is generally preferred over shfs, the latter has not been updated since 2004.

By default, the SSH session automatically logs out if it has been idle for a certain time. To keep the session up, the client can send a keep-alive signal to the server if no data has been received for some time, or symmetrically the server can send messages at regular intervals if it has not heard from the client.

  • On the server side, ClientAliveInterval sets the timeout in seconds after which if no data has been received from the client, sshd will send a request for response. The default is 0, no message is sent. For example to request a response every 60 seconds from the client, set the ClientAliveInterval 60 option in your server configuration. See also the ClientAliveCountMax and TCPKeepAlive options.
  • On the client side, ServerAliveInterval controls the interval between the requests for response sent from the client to the server. For example to request a response every 120 seconds from the server, add the ServerAliveInterval 120 option to your client configuration. See also the ServerAliveCountMax and TCPKeepAlive options.

Note: To ensure a session is kept alive, only one of either the client or the server needs to send keep alive requests. If ones control both the servers and the clients, a reasonable choice is to only configure the clients that require a persistent session with a positive ServerAliveInterval and leave other clients and servers in their default configuration.

Automatically restart SSH tunnels with systemd

systemd can automatically start SSH connections on boot/login and restart them when they fail. This makes it a useful tool for maintaining SSH tunnels.

~/.config/systemd/user/tunnel.service
[Unit]
Description=SSH tunnel to myserver

[Service]
Type=simple
Restart=always
RestartSec=10
ExecStart=/usr/bin/ssh -F %h/.ssh/config -N myserver

Autossh — automatically restarts SSH sessions and tunnels

When a session or tunnel cannot be kept alive, for example due to bad network conditions causing client disconnections, you can use to automatically restart them.

$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" username@example.com

Combined with SSHFS:

$ sshfs -o reconnect,compression=yes,transform_symlinks,ServerAliveInterval=45,ServerAliveCountMax=2,ssh_command='autossh -M 0' username@example.com: /mnt/example 

Connecting through a SOCKS-proxy set by Proxy settings:

$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" -NCD 8080 username@example.com 

With the -f option autossh can be made to run as a background process. Running it this way however means the passphrase cannot be entered interactively.

The session will end once you type exit in the session, or the autossh process receives a SIGTERM, SIGINT of SIGKILL signal.

Run autossh automatically at boot via systemd

If you want to automatically start autossh, you can create a systemd unit file:

/etc/systemd/system/autossh.service
[Unit]
Description=AutoSSH service for port 2222
After=network.target

[Service]
Environment="AUTOSSH_GATETIME=0"
ExecStart=/usr/bin/autossh -M 0 -NL 2222:localhost:2222 -o TCPKeepAlive=yes foo@bar.com

[Install]
WantedBy=multi-user.target

Here AUTOSSH_GATETIME=0 is an environment variable specifying how long ssh must be up before autossh considers it a successful connection, setting it to 0 autossh also ignores the first run failure of ssh. This may be useful when running autossh at boot. Other environment variables are available at . Of course, you can make this unit more complex if necessary (see the systemd documentation for details), and obviously you can use your own options for autossh, but note that the -f implying AUTOSSH_GATETIME=0 does not work with systemd.

Remember to start and/or enable the service afterwards.

You may also need to disable ControlMaster e.g.

ExecStart=/usr/bin/autossh -M 0 -o ControlMaster=no -NL 2222:localhost:2222 -o TCPKeepAlive=yes foo@bar.com

Tip: It is also easy to maintain several autossh processes, to keep several tunnels alive. Just create multiple service files with different names.

Alternative service should SSH daemon fail

/etc/systemd/system/sshd.service.d/override.conf
[Unit]
OnFailure=telnet.socket

That’s it. Telnet is not available when sshd is running. Should sshd fail to start, a telnet session can be opened for recovery.

Terminal background color based on host

To better distinguish when you are on different hosts, you can set a different background color based on the kind of host.

This solution works, but is not universal (ZSH only).

Network specific configuration

You can use host configuration specific to the network you are connected to using a Match exec.

For example, when using , and the connection is configured (manually or through DHCP) to use a search-domain:

Match exec "nmcli | grep domains: | grep example.com"
  CanonicalDomains example.com
  # Should you use a different username on this network
  #User username
  # Use a different known_hosts file (for private network or synchronisation)
  #UserKnownHostsFile <network>_known_hosts
Match host internal.example.com !exec "host internal.example.com"
  ProxyJump bastion.example.com
Host internal.example.com
  User foobar

Private networks hostkeys verification

Tango-inaccurate.pngThe factual accuracy of this article or section is disputed.Tango-inaccurate.png

Reason: The best solution would not need a warning to use something else in practice. (Discuss in Talk:OpenSSH)

Host 10.* 192.168.*.* 172.31.* 172.30.* 172.2?.* 172.1?.*
    # Disable HostKey verification
    # Trust HostKey automatically
    StrictHostKeyChecking no
    # Do not save the HostKey
    UserKnownHostsFile=/dev/null
    # Do not display: "Warning: Permanently Added ..."
    LogLevel Error

Tango-inaccurate.pngThe factual accuracy of this article or section is disputed.Tango-inaccurate.png

Reason: The known_hosts file records an IP address even when you use hostname to access the server. (Discuss in Talk:OpenSSH)

Warning: In a production environment, make sure to either use the hostname to access the host and/or to use network specific known_hosts files.

Run command at login

If you are using an interactive session, there are multiple ways to execute a command on login:

  • use the authorized_keys file on the remote host (see AUTHORIZED_KEYS FILE FORMAT in )
  • use ~/.ssh/rc on the remote host if the server has enabled the PermitUserRC option
  • use your shell configuration file on the remote host, e.g. .bashrc

SSH agent forwarding allows you to use your local keys when connected to a server. It is recommended to only enable agent forwarding for selected hosts.

~/.ssh/config
Host myserver.com
    ForwardAgent yes

Next, configure an SSH agent and add your local key with ssh-add.

If you now connect to a remote server you will be able to connect to other services using your local keys.

Generating new keys

New server private keys can be generated by:

  1. Deleting all the keys, e.g.:
    # rm /etc/ssh/ssh_host_*_key*
  2. Restarting sshdgenkeys.service or running ssh-keygen -A as root.

$ ssh-keygen -q -N "" -t rsa -b 4096 -f /path/to/host/keys/ssh_host_rsa_key
$ ssh-keygen -q -N "" -t ecdsa -f /path/to/host/keys/ssh_host_ecdsa_key
$ ssh-keygen -q -N "" -t ed25519 -f /path/to/host/keys/ssh_host_ed25519_key

Create an sshd_config file. The example below uses a port higher than 1024, provides a new path to the host keys and disables PAM:

/path/to/sshd_config
Port 2022
HostKey /path/to/host/keys/ssh_host_rsa_key
HostKey /path/to/host/keys/ssh_host_ecdsa_key
HostKey /path/to/host/keys/ssh/ssh_host_ed25519_key
UsePAM no

Run sshd with the created config. The -D flag disables daemon mode and -e redirects output to stderr to allow easy monitoring.

$ sshd -f /path/to/sshd_config -D -e

Дополнительно:  Как исправить ошибку 0x0000006F?
Оцените статью
Master Hi-technology
Добавить комментарий