text:
Secure Shell (SSH) is a network protocol that allows data to be exchanged over a secure channel between two computers. Encryption provides confidentiality and integrity of data. SSH uses public-key cryptography to authenticate the remote computer and allow the remote computer to authenticate the user, if necessary.
SSH is typically used to log into a remote machine and execute commands, but it also supports tunneling, forwarding arbitrary TCP ports and X11 connections; file transfer can be accomplished using the associated SFTP or SCP protocols.
An SSH server, by default, listens on the standard TCP port 22. An SSH client program is typically used for establishing connections to an sshd daemon accepting remote connections. Both are commonly present on most modern operating systems, including macOS, GNU/Linux, Solaris and OpenVMS. Proprietary, freeware and open source versions of various levels of complexity and completeness exist.
- 1 OpenSSH
- 1.1 Installation
- 1.2 Client usage
- 1.3 Server usage
- 1.3.1 Configuration
- 1.3.2 Daemon management
- 1.3.3 Protection
- 2 Other SSH clients and servers
- 3 Tips and tricks
- 3.1 Encrypted SOCKS tunnel
- 3.2 X11 forwarding
- 3.3 Forwarding other ports
- 3.4 Multiplexing
- 3.5 Speeding up SSH
- 3.6 Mounting a remote filesystem with SSHFS
- 3.7 Keep alive
- 3.8 Automatically restart SSH tunnels with systemd
- 3.9 Autossh - automatically restarts SSH sessions and tunnels
- 4 Troubleshooting
- 4.1 Checklist
- 4.2 SSH connection hangs after poweroff/reboot
- 4.3 Connection refused or timeout problem
- 4.3.1 Port forwarding
- 4.3.2 Is SSH running and listening?
- 4.3.3 Are there firewall rules blocking the connection?
- 4.3.4 Is the traffic even getting to your computer?
- 4.3.5 Your ISP or a third party blocking default port?
- 4.3.6 Read from socket failed: connection reset by peer
- 4.4 "[your shell]: No such file or directory" / ssh_exchange_identification problem
- 4.5 "Terminal unknown" or "Error opening terminal" error message
- 4.6 Connection closed by x.x.x.x [preauth]
- 4.7 id_dsa refused by OpenSSH 7.0
- 4.8 No matching key exchange method found by OpenSSH 7.0
- 5 See also
OpenSSH (OpenBSD Secure Shell) is a set of computer programs providing encrypted communication sessions over a computer network using the 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.
Client usage
To connect to a server, run:
$ ssh -p port user@server-address
If the server only allows public-key authentication, follow SSH 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:
# global options User user # host-specific options Host myserver HostName server-address Port port
With such a configuration, the following commands are equivalent
$ ssh -p port user@server-address $ ssh myserver
See ssh_config(5) for more information.
Some options do not have command line switch equivalents, but you can specify config options on the command line with
-o. For example
Server usage
The SSH daemon configuration file can be found and edited in
To allow access only for some users add this line:
AllowUsers user1 user2
To allow access only for some groups:
AllowGroups group1 group2
To disable root login over SSH, change the PermitRootLogin line into this:
PermitRootLogin no
PermitRootLogin prohibit-password is the default since version 7.0p1. See sshd_config(5).
To add a nice welcome message (e.g. from the
/etc/issue file), configure the
Banner option:
Banner /etc/issue
Host keys will be generated automatically by the sshd service files. If you want sshd to use a particular key which you have provided, you can configure it manually:
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 a port review the list of TCP and UDP port numbers. You can also find port information locally in
/etc/services. Select an alternative port that is not already assigned to a common service to prevent conflicts. A port change from default port 22 is recommended, because it will reduce the number of log entries caused by automated authentication attempts - not eliminate them. See Port knocking for related information.
It is also recommended to disable password logins entirely. This will greatly increase security, see #Force public key authentication for more information.
Daemon management
openssh comes with two kinds of systemd service files:
sshd.service, which will keep the SSH daemon permanently active and fork for each incoming connection.[1] It is especially suitable for systems with a large amount of SSH traffic.[2]
sshd@.service, which spawn on-demand instances of the SSH daemon per connection. Using it implies that systemd listens on the SSH socket and will only start the daemon process for an incoming connection. It is the recommended way to run
sshdin almost all cases.[3][4][5]
You can start and enable either
sshd.service or
sshd.socket to begin using the daemon.
If using the socket service, you will need to edit the unit file if you want it to listen on a port other than the default 22:
# systemctl edit sshd.socket
[Socket] ListenStream= ListenStream=12345
sshd.socket negates the
ListenAddress setting, so it will allow connections over any address. To achieve the effect of setting
ListenAddress, you must specify the port and IP for
ListenStream (e.g.
ListenStream=192.168.1.100:22). You must also add
FreeBind=true under
[Socket] or else setting the IP address will have the same drawback as setting
ListenAddress: the socket will fail to start if the network is not up in time.
sshd.socket nor the daemon's regular
sshd.service allow to monitor connection attempts in the log, but executing
# journalctl /usr/bin/sshd does.
Allowing remote log-on through SSH is good for administrative purposes, but can pose a threat to your server's security. Often the target of brute force attacks, SSH access needs to be limited properly to prevent third parties gaining access to your server.
Several other good guides are available on the topic, for example:
Force public key authentication
If a client cannot authenticate through a public key, by default the SSH server falls back to password authentication, thus allowing a malicious user to attempt to gain access by brute-forcing the password. One of the most effective ways to protect against this attack is to disable password logins entirely, and force the use of SSH keys. This can be accomplished by disabling the following options in
PasswordAuthentication no ChallengeResponseAuthentication no
authorized_keys files. See SSH keys#Copying the public key to the remote server for more information.
Two-factor authentication and public keys
Since OpenSSH 6.2, you can add your own chain to authenticate with 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.
To use PAM with OpenSSH, edit the following files:
ChallengeResponseAuthentication yes AuthenticationMethods publickey keyboard-interactive:pam
Then you can log in with either a publickey or the user authentication as required by your PAM setup.
If, on the other hand, you want to authenticate the user on both a publickey and the user authentication as required by your PAM setup, use a comma instead of a space to separate the AuthenticationMethods:
ChallengeResponseAuthentication yes AuthenticationMethods publickey,keyboard-interactive:pam
With required pubkey and pam authentication you may wish to disable the password requirement:
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
Brute forcing is a simple concept: One continuously tries to log in to a webpage or server log-in prompt like SSH with a high number of random username and password combinations.
Using iptables
If you are already using iptables you can easily protect SSH against brute force attacks by using the following rules.
Before the following rules can be used we create a new rule chain to log and drop to many connection attempts:
# iptables -N LOG_AND_DROP
The first rule will be applied to packets that signal the start of new connections headed for TCP port 42660
# iptables -A INPUT -p tcp -m tcp --dport 42660 -m state --state NEW -m recent --set --name DEFAULT --rsource
The next rule tells iptables to look for packets that match the previous rule's parameters, and which also come from hosts already added to the watch list.
# iptables -A INPUT -p tcp -m tcp --dport 42660 -m state --state NEW -m recent --update --seconds 90 --hitcount 4 --name DEFAULT --rsource -j LOG_AND_DROP
Now iptables decides what to do with TCP traffic to port 42660 which does not match the previous rule.
# iptables -A INPUT -p tcp -m tcp --dport 42660 -j ACCEPT
We are appending this rule to the LOG_AND_DROP table, and we use the -j (jump) operator to pass the packet's information to the logging facility
# iptables -A LOG_AND_DROP -j LOG --log-prefix "iptables deny: " --log-level 7
After they are logged by the first rule, all packets are then dropped
# iptables -A LOG_AND_DROP -j DROP
Anti-brute-force tools
You can protect yourself from brute force attacks by using an automated script that blocks anybody trying to brute force their way in, for example fail2ban or sshguard.
- 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
It is generally considered bad practice to allow the root user to log in without restraint over SSH. There are two methods by which SSH root access can be restricted for increased security.
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.
SSH can be configured to deny remote logins with the root user by editing the "Authentication" section in
/etc/ssh/sshd_config. Simply change
#PermitRootLogin prohibit-password to
no and uncomment the line:
PermitRootLogin no ...
Next, restart the SSH daemon.
You will now be unable to log in through SSH under root, but will still be able to log in with your normal user and use su or sudo to do system administration.
Some automated tasks such as remote, full-system backup require full root access. To allow these in a secure way, instead of disabling root login via SSH, it is possible to only allow root logins for selected commands. This can be achieved by editing
~root/.ssh/authorized_keys, by prefixing the desired key, e.g. as follows:
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.
The increased attack surface created by exposing the root user name at login can be compensated by adding the following to
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 without-password
For additional protection, you can prevent users from adding new public keys and connecting from them.
In the server, make the
authorized_keys file read-only for the user and deny all other permissions:
$ chmod 400 ~/.ssh/authorized_keys
To keep the user from simply changing the permissions back, set the immutable bit on the
authorized_keys file. After that the user could rename the
~/.ssh directory to something else and create a new
~/.ssh directory and
authorized_keys file. To prevent this, set the immutable bit on the
~/.ssh directory too.
authorized_keys and make it writable. Follow the steps above to secure it again.
Other SSH clients and servers
Apart from OpenSSH, there are many SSH clients and servers available.
Dropbear is a SSH-2 client and server. dropbear is available in the official repositories.
The command-line ssh client is named dbclient.
From the Mosh website:
- Remote terminal application that allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes. Mosh is a replacement for SSH. It is more robust and responsive, especially over slow connections such as Wi-Fi, cellular, and long-distance.
Install the mosh package, or mosh-gitAUR for the latest revision.
Mosh has an undocumented command line option
--predict=experimental which produces more aggressive echoing of local keystrokes. Users interested in low-latency visual confirmation of keyboard input may prefer this prediction mode.
Tips and tricks
Encrypted SOCKS tunnel
This is highly useful for laptop users connected to various unsafe wireless connections. The only thing you need is an SSH server running at a somewhat secure location, like your home or at work. It might be useful to use a dynamic DNS service like DynDNS so you do not have to remember your IP-address.
Step 1: start the connection
You only have to execute this single command to start the connection:
$ ssh -TND 4711 user@host
user is your username at the SSH server running at the
host. It will ask for your password, and then you are connected! The
N flag disables the interactive prompt, and the
D flag specifies the local port on which to listen on (you can choose any port number if you want). The
T flag disables pseudo-tty allocation.
It is nice to add the verbose (
-v) flag, because then you can verify that it is actually connected from that output.
Step 2: configure your browser (or other programs)
The above step is completely useless if you do not configure your web browser (or other programs) to use this newly created socks tunnel. Since the current version of SSH supports both SOCKS4 and SOCKS5, you can use either of them.
- For Firefox: Edit > Preferences > Advanced > Network > Connection > Setting:
Check the Manual proxy configuration radio button, and enter
localhostin the SOCKS host text field, and then enter your port number in the next text field (
4711in the example above).
Firefox does not automatically make DNS requests through the socks tunnel. This potential privacy concern can be mitigated by the following steps:
- Type about:config into the Firefox location bar.
- Search for network.proxy.socks_remote_dns
- Set the value to true.
- Restart the browser.
- 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
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!
X11 forwarding
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).
On the remote system:
- install xorg-xauth and xorg-xhost from the official repositories
- in
- verify that
X11UseLocalhostoptions are set to yes, and that
X11DisplayOffsetis set to 10 (those are the default values if nothing has been changed, see sshd_config(5))
- set
X11Forwardingto yes
- verify that
- then restart the sshd daemon.
On the client's side, 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.
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
You can now start any X program on the remote server, the output will be forwarded to your local session:
$ xclock
If you get "Cannot open display" errors try the following command as the non root user:
$ xhost +
The above command will allow anybody to forward X11 applications. To restrict forwarding to a particular host type:
$ xhost +hostname
where hostname is the name of the particular host you want to forward to. See xhost(1) for more details.
Be careful with some applications as they check for a running instance on the local machine. Firefox is an example: either close the running Firefox instance or use the following start parameter to start a remote instance on the local machine:
$ 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 xorg-xauth is installed. If its installation is not working, try to either:
- enable the
AddressFamily anyoption in
sshd_configon the server, or
- set the
AddressFamilyoption in
sshd_configon the server to inet.
Setting it to inet may fix problems with Ubuntu clients on IPv4.
For running X applications as other user on the SSH server you need to
xauth add the authentication line taken from
xauth list of the SSH logged in user.
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 as between the local machine and 192.168.0.100, but not between 192.168.0.100, 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.freenode.net:6667 192.168.0.200
will bring up a shell on 192.168.0.200, and connections from 192.168.0.200 to itself on port 3000 (remotely speaking, localhost:3000) will be sent over the tunnel to the local machine and then on to irc.freenode.net on port 6667, thus, in this example, allowing the use of IRC programs on the remote host to be used, even if port 6667 would normally be blocked to it.
Both local and remote forwarding can be used to provide a secure "gateway," allowing other computers to take advantage of an SSH tunnel, without actually running SSH or the SSH daemon by providing a bind-address for the start of the tunnel as part of the forwarding specification, e.g.
<tunnel address>:<tunnel port>:<destination address>:<destination port>. The
<tunnel address> can be any address on the machine at the start of the tunnel,
* (or blank), which, respectively, allow connections via the given address, via the loopback interface, or via any interface. By default, forwarding is limited to connections from the machine at the "beginning" of the tunnel, i.e. the
<tunnel address> is set to
localhost. Local forwarding requires no additional configuration, however remote forwarding is limited by the remote server's SSH daemon configuration. See the
GatewayPorts option in
sshd_config(5) for more information.
The SSH daemon usually listens on port 22. However, it is common practice for many public internet hotspots to block all traffic that is not on the regular HTTP/S ports (80 and 443, respectively), thus effectively blocking SSH connections. The immediate solution for this is to have
sshd listen additionally on one of the whitelisted ports:
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 sslh, 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 ssh_config(5) for full descriptions of these options.
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
~/.ssh/sockets can be any directory not writable by other users.
Another option to improve speed is to enable compression with the
Compression yes option or the
-C flag.
Login time can be shortened by bypassing IPv6 lookup using the
AddressFamily inet option or
-4 flag.
Mounting a remote filesystem with SSHFS
Please refer to the Sshfs article to use sshfs to mount a remote system - accessible via SSH - to a local folder, so you will be able to do any operation on the mounted files with any tool (copy, rename, edit with vim, etc.). Using sshfs instead of shfs is generally preferred as a new version of shfs has not been released since 2004.
Keep alive
Your ssh session will automatically log out if it is idle. To send a "keep alive" signal to the server every 120 seconds add the
ServerAliveInterval 120 option to your client configuration. See also the
ServerAliveCountMax and
TCPKeepAlive options.
Conversely, to keep incoming connections alive, set the
ClientAliveInterval option in your server 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.
The following service can start an SSH tunnel on login using the connection settings in your ssh config. If the connection closes for any reason, it waits 10 seconds before restarting it:
[Unit] Description=SSH tunnel to myserver [Service] Type=simple Restart=always RestartSec=10 ExecStart=/usr/bin/ssh -F %h/.ssh/config -N myserver
Then enable and start the user service. See #Keep alive for how to prevent the tunnel from timing out. If you wish to start the tunnel on boot, you will need to rewrite the unit as a system service.
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 autossh to automatically restart them.
Usage examples:
$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" firstname.lastname@example.com
Combined with sshfs:
$ sshfs -o reconnect,compression=yes,transform_symlinks,ServerAliveInterval=45,ServerAliveCountMax=2,ssh_command='autossh -M 0' email@example.com: /mnt/example
Connecting through a SOCKS-proxy set by Proxy settings:
$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" -NCD 8080 email@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:
[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 firstname.lastname@example.com [Install] WantedBy=multi-user.target
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 on the manpage. 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 email@example.com
Check these simple issues before you look any further.
- The config directory
~/.sshand its contents should be accessible only by your user (check this on both the client and the server):
$ chmod 700 ~/.ssh $ chmod 600 ~/.ssh/* $ chown -R $USER ~/.ssh
- Check that the client's public key (e.g.
id_rsa.pub) is in
~/.ssh/authorized_keyson the server.
- Check that you did not limit SSH access with
AllowGroupsin the server config.
- 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.
- Restart
sshdand logout/login on both client and server.
SSH connection hangs after poweroff/reboot
SSH connections hang after poweroff or reboot if systemd stops the network before sshd. To fix this, change the
After statement for user sessions:
# systemctl edit systemd-user-sessions.service
[Unit] After=network.target
Connection refused or timeout problem
Port forwarding
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 -tnlp
If the above command do not show SSH port is open, SSH is NOT running. Check
/var/log/messages for errors etc.
Are there firewall rules blocking the connection?
Iptables may be blocking connections on port
22. Check this with:
# iptables -nvL
and look for rules that might be dropping packets on the
INPUT chain. Then, if necessary, unblock the port with a command like:
# iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT
For more help configuring firewalls, see firewalls.
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
This should show some basic information, then wait for any matching traffic to happen before displaying it. Try your connection now. If you do not see any output when you attempt to connect, then something outside of your computer is blocking the traffic (e. g., hardware firewall, NAT router etc.).
Your ISP or a third party blocking default port?
In some cases, your ISP might block the default port (SSH port 22) so whatever you try (opening ports, hardening the stack, defending against flood attacks, et al) ends up useless. To confirm this, create a server on all interfaces (0.0.0.0) and connect remotely.
If you get an error message comparable to this:
ssh: connect to host www.inet.hr port 22: Connection refused
That means the port is not being blocked by the ISP, but the server does not run SSH on that port (See security through obscurity).
However, if you get an error message comparable to this:
ssh: connect to host 111.222.333.444 port 22: Operation timed out
That means that something is rejecting your TCP traffic on port 22. Basically that port is stealth, either by your firewall or 3rd party intervention (like an ISP blocking and/or rejecting incoming traffic on port 22). If you know you are not running any firewall on your computer, and you know that Gremlins are not growing in your routers and switches, then your ISP is blocking the traffic.
To double check, you can run Wireshark on your server and listen to traffic on port 22. Since Wireshark is a Layer 2 Packet Sniffing utility, and TCP/UDP are Layer 3 and above (see IP Network stack), if you do not receive anything while connecting remotely, a third party is most likely to be blocking the traffic on that port to your server.
Install either tcpdump or Wireshark with the wireshark-cli package.
For tcpdump:
# tcpdump -ni interface "port 22"
For Wireshark:
$ tshark -f "tcp port 22" -i interface
interface is the network interface for a WAN connection (see
ip a to check). If you are not receiving any packets while trying to connect remotely, you can be very sure that your ISP is blocking the incoming traffic on port 22.
Possible solution
The solution is just to use some other port that the ISP is not blocking. Open the
/etc/ssh/sshd_config and configure the file to use different ports. For example, add:
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
Recent versions of openssh sometimes fail with the above error message when connecting to older ssh servers. This can be worked around by setting various client options for that host. See ssh_config(5) for more information about the following options.
The problem could be the
ecdsa-sha2-nistp*-cert-v01@openssh elliptical host key algorithms. These can be disabled by setting
HostKeyAlgorithms to a list excluding those algorithms.
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
See also the discussion on the openssh bug forum.
"[your shell]: No such file or directory" / ssh_exchange_identification problem
One possible cause for this is the need of certain SSH clients to find an absolute path (one returned by
whereis -b [your shell], for instance) in
$SHELL, even if the shell's binary is located in one of the
$PATH entries.
"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.
TERM hack
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.
Connection closed by x.x.x.x [preauth]
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
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 config option
PubkeyAcceptedKeyTypes +ssh-dss (http://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 http://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.
See also
- Wikipedia:Secure Shell
- Defending against brute force ssh attacks
- OpenSSH key management, Part 1 and Part 2 on IBM developerWorks
- Secure Secure Shell


text:
This month's readings bring to life Elijah, Elisha, Amos, and Hosea, prophets who turn up the heat on the status quo. They show us how God speaks through flame, smoke, water, and wind. Through poems, songs, stories, and powerful monologues, prophets are God's representatives in human history.
In their introduction to The Inclusive Hebrew Scriptures: The Prophets, Craig Smith and Mark Buckley explain both the definition and role of a prophet. "Prophet" means "to speak for," which means the prophet also shares what Abraham Heschel calls "the pathos of God's heart." The prophet listens to, understands, and finally proclaims a message that comes from the very heart of God.
The four prophets, using the language of repentance, call the children of Abraham to return to faithful living. God's uniqueness, faithfulness to covenant, justice, and kindness all mingle to create a portrait of God that confuses and distresses as much as it reveals. But this is not a bad place to be. As Smith and Buckley write, "Prophets revive our capacity to feel and draw our attention to what we would rather not see."
Paired with stories of Jesus' ministry from Luke's gospel, episodes from the prophets' lives can take on new meaning in a world that desperately needs to hear righteous words of judgment and healing. These words can save us from ourselves, but only if we are willing to be led to God's heart.
Malinda Elizabeth Berry is a dissertation fellow at Goshen College in Goshen, Indiana.
July 1
Refining Fire
2 Kings 2:1-2, 6-14; Psalm 77:1-2, 11-20; Galatians 5:1, 13-25; Luke 9:51-62
As a child, an illustration in my sister's Bible especially caught my eye. It was of Elijah being taken up to heaven in a chariot of fire. I hadn't remembered this story from Sunday school, or at least it failed to make an impression on me. But I was fascinated by this illustration.

subset: commoncrawl


text:
Cool chambray background is accented with decorative piping. 100% cotton, 200 thread count cotton percale; hidden-button closure.
Care: Machine wash warm, tumble dry low. Warm iron if needed.
Dimensions: Twin 68" X 86"
Would you like us to help you find a similar item? Talk with our Design Consultants toll-free at1-800-927-5164.
*Shipping transit time varies based on destination. Free shipping offers are limited to the 48 contiguous states of the USA.
International Customers (including Alaska and Hawaii) please contact a Customer Service Representative if you have any questions about placing an order with PoshTots.
Promotion codes cannot be used for sale item purchases.
*Free shipping offers are limited to the 48 contiguous states of the USA.


text:
Pride Center
Pride Center: Response to COVID-19
In response to Los Angeles Mayor Eric Garcetti's "New City Measures to Address COVID-19" (3/15/2020) and the Health Officer Order (3/21/2020), the Pride Center of the University Student Union will be providing services remotely. Read more about our response to COVID-19.
A Part of the University Student Union at CSUN
Be You.
The Pride Center supports lesbian, gay, bisexual, transgender, queer, questioning, intersex and asexual (LGBTQIA+) students, faculty and staff through programming and educational outreach to improve the campus climate for LGBTQIA+ individuals as well as advocate for the respect and safety of all members of the campus community.
Pride Center Values: Advocacy, Communication, Empowerment, Fun, Inclusivity, Intersectionality, Learning, Social Justice
The University Student Union at CSUN includes the Pride Center, Computer Lab, East Conference Center, Games Room, Northridge Center, Oasis Wellness Center, Reservations & Event Services, Student Recreation Center, USU Events, Veterans Resource Center...and you!
Events and News
Upcoming Events
CANCELED — Pride Center: Tuesday Talks
Tuesday, May 5, 2020 - 7:00pm to 8:30pm
The Pride Center of the University Student Union invites CSUN LGBTQIA+ students and allies to join us for Tuesday Talks. Come hang out and discuss compelling topics concerning the LGBTQIA+ community. Read more
CANCELED — Pride Center: T-Time
Wednesday, May 6, 2020 - 7:00pm to 8:30pm
Build your community in a safe space with fellow transgender, gender questioning and genderqueer Matadors every Wednesday during T-Time, hosted by the Pride Center! Read more
CANCELED — Pride Center: LGBTQIA+ Coffee Nights
Thursday, May 7, 2020 - 5:00pm to 7:00pm
All CSUN students, staff and allies of the LGBTQIA+ community are invited to come by and enjoy our comfortable TV lounge, exciting games, cool crafts and good conversation with welcoming people. Read more


text:
Bail revoked for man accused of videotaping women
Michael McKenny accused of setting up cameras in condo
Bail has been taken away from a Columbia man accused of secretly videotaping two women inside their Ellicott City home.
Howard County police arrested Michael McKenny, 42, hours after releasing a video to the public that they said showed him setting up the cameras inside the women's condo.
McKenny was charged with burglary, visual surveillance with prurient intent and other offenses. A judge decided Tuesday to revoke McKenny's initial $100,000 bail, but the reason behind the decision wasn't clear.
Detectives said McKenny knew the identities of the roommates and had stolen and copied the key to their condo. Police said the camera was first set up in June, and the man went back into the condo several times to move it around.
The women discovered the video camera hidden in a closet last month.
Investigators are still trying to figure out if McKenny was targeting other victims.


text:
Liberty News
Finance Department hires two new directors
|Robert Wells, director of Risk Management
Liberty University recently hired two new directors in its Finance Department as the school moves toward 100,000 students enrolled and remains the largest private, nonprofit, four-year college in the country and the world's largest Christian university.
Robert Wells started last month as Liberty's first director of Risk Management. He comes to Liberty from Chesapeake, Va., where he was director of purchasing and insurance for the Christian Broadcasting Network.
A native of Amherst County, he was thrilled to return to his roots.
"For me, I couldn't have imagined a better fit, somewhere I was familiar with and doing the type of work I've been doing for over 20 years," Wells said.
He said the new role was necessitated by the "tremendous growth" at the university, especially with a quarter of a billion dollar campus transformation under way and the amount of contracts that must be reviewed, "but that's what I enjoy, the challenge."
Wells holds a B.S. in Business from Lynchburg College and a CPCU certification in insurance.
Liberty also welcomed Deb Nightingale as its new director of Card Services in August, bringing with her more than 20 years of experience meeting college students' needs through their campus ID cards. She administers all aspects of Liberty's card, called the Flames Pass, which gives students access to meal plans, Flames Cash (also used at off-campus locations), book vouchers, book dollars, discounts, and to recreational and athletic facilities and Student Activities events.
|Deb Nightingale, director of Card Services
Nightingale came to Liberty from Gorham, Maine, where she worked for the University of Southern Maine and served for 11 years as the school's assistant director of Card Services.
Since she has been at Liberty, Card Services has already expanded its offerings for students.
"We're looking to provide more services, to enhance and make their life on campus a little bit easier," she said, like using Flames Cash at hockey game concessions. Possibilities for use also include Liberty Mountain Snowflex Centre and Postal Services.
The office is also providing other departments useful data and demographic information from the Flames Pass, including facility usage, peak times, etc., and is working closely with Access Control to make entries into events and residence halls more secure.
Nightingale said working in a Christian environment is the best perk of the job.
"I constantly pinch myself — it's overwhelming for me," she said. "I love Convocation, being able to pray with staff, I love walking through the halls and seeing staff members pray for each other. … It's confirmation I was supposed to be here. I know God has me here to grow me even more and Liberty is a great place to do that."
Nightingale holds a B.S. in Applied Technical Education from University of Southern Maine and is a certified operator, CBord (one-card system) and CCure (access control).


text:
watch 02:17
The Loop (Games)
Do you like this video?
Meteorite Ore comes from Meteorites, which have a chance of appearing each night at midnight after a Shadow Orb (Or Pulsing Heart) has been broken. The amount of Meteorite Ore that appears depends on where the Meteorite lands, as Meteorite Ore will replace existing blocks rather than creating new blocks. For this reason, it is recommended that you not build any Skybridges until after you no longer need Meteorite; if a Meteorite hits a Skybridge, it will not have many blocks to replace therefore little Meteorite Ore will be made.
Meteorite blocks are fire-type, so an Obsidian Skull, Obsidian Shield, Obsidian Horseshoe, Obsidian Water Walking Boots, or Obsidian Skin Potion is required to prevent damage from touching them. A Gold Pickaxe or better is required to mine the Meteorite Ore, although explosives work just as well. It is safe to touch the loose ore after it's been mined. Three Meteorite Ore can be smelted into a Meteorite Bar at a Furnace.
Meteor Heads have a 2% (1:50) drop rate of Meteorite Ore. If you continuously want to farm the ores then this is a slow, but possible process.
Tips and Tricks
- Keeping the Meteor Heads in front will allow the player to continuously knock them back while mining.
- Only a certain number of Meteor Heads (usually 3 to 6) will spawn at a time, unless the player is unfortunate enough to attempt to mine during a Blood Moon, in which case they will spawn in overwhelming quantities.
- Once there is less than 50 Meteorite Ore placed in the immediate area, the "Eerie" theme which normally plays around Meteorite deposits will revert to normal and Meteor Heads will cease to spawn.
- When a player is in a Meteorite biome, only Meteor Heads will spawn, unless you are also in an Ocean biome.
- The player can place 50 Meteorite Ore to create an artificial Meteorite biome, which has the same properties as a natural Meteorite. This can be done to prevent more dangerous monsters from spawning.
- It is possible to gather all of the Meteorite Ore without an Obsidian Skull as long as the player does not directly touch the Meteorite blocks.
- Using Dynamite to destroy most of the Meteorite Ore at once will make it easier to collect it, as well as stopping the Meteor Heads from spawning much sooner.
- Using Bombs is also an alternative to using Dynamite as it is much cheaper, and also due to the fact that they can be made into Sticky Bombs. Using Sticky Bombs allows you to position where you want the explosion, as you do not have to worry about bouncing. The only downside to this method is that it takes longer to mine the Meteorite as Bombs lack the large explosion radius of Dynamite.
- Standing on the Meteorite with strong armor helps to be able to ignore the heads that appear, though by the time you can safely use this technique, you won't have much use for Meteorite.
- Meteorite Ore will still burn you even if submerged underwater.
Update Info
- Added to the game.
|Original Metals
|Alternative Metals
|Hard Mode Metals
|Other Minerals & Materials
|Items Requiring Meteorite
|Meteor Hamaxe
|Star Cannon · Space Gun · Phaseblades · ?
|Meteor Helmet · Meteor Suit · Meteor Leggings
|Meteor Shot
|Meteorite Bar
Community content is available under CC-BY-SA unless otherwise noted.