Linux command to wait for a SSH server to be up

I don't have a host that I can ssh to and control whether it's up or not, but this should work:

while ! ssh <ip>
do
    echo "Trying again..."
done

Or a shell script that is more explicit:

#!/bin/sh

ssh $1
while test $? -gt 0
do
   sleep 5 # highly recommended - if it's in your local network, it can try an awful lot pretty quick...
   echo "Trying again..."
   ssh $1
done

Save it as (say) waitforssh.sh and then call it with sh waitforssh.sh 192.168.2.38

This is a 'ping_ssh' script I'm using. It handles timeout cases, fast success, and won't prompt for passwords or be fooled by the port being open but not responding as with 'nc' based solutions. This combines several answers found on various stackoverflow related sites.

#!/usr/bin/bash
HOST=$1
PORT=$2
#HOST="localhost"
#PORT=8022
if [ -z "$1" ]
  then
    echo "Missing argument for host."
    exit 1 
fi

if [ -z "$2" ]
  then
    echo "Missing argument for port."
    exit 1 
fi
echo "polling to see that host is up and ready"
RESULT=1 # 0 upon success
TIMEOUT=30 # number of iterations (5 minutes?)
while :; do 
    echo "waiting for server ping ..."
    # https://serverfault.com/questions/152795/linux-command-to-wait-for-a-ssh-server-to-be-up
    # https://unix.stackexchange.com/questions/6809/how-can-i-check-that-a-remote-computer-is-online-for-ssh-script-access
    # https://stackoverflow.com/questions/1405324/how-to-create-a-bash-script-to-check-the-ssh-connection
    status=$(ssh -o BatchMode=yes -o ConnectTimeout=5 ${HOST} -p ${PORT} echo ok 2>&1)
    RESULT=$?
    if [ $RESULT -eq 0 ]; then
        # this is not really expected unless a key lets you log in
        echo "connected ok"
        break
    fi
    if [ $RESULT -eq 255 ]; then
        # connection refused also gets you here
        if [[ $status == *"Permission denied"* ]] ; then
            # permission denied indicates the ssh link is okay
            echo "server response found"
            break
        fi
    fi
    TIMEOUT=$((TIMEOUT-1))
    if [ $TIMEOUT -eq 0 ]; then
        echo "timed out"
        # error for jenkins to see
        exit 1 
    fi
    sleep 10
done

Something simple like this does the job, waiting 5 seconds between attempts and discarding STDERR

until ssh <host> 2> /dev/null
  do
    sleep 5
  done

The ssh command can be given a command to perform on the remote machine as the last paramater. So call ssh $MACHINE echo in a loop. On success it returns 0 in $?, on failure 255. You must of course use paswordless authentication with certificates.

Well, I'm not sure what you mean by to be up, but what about:

$ ping host.com | grep --line-buffered "bytes from" | head -1 && ssh host.com

First command ping | ... | head -1 waits for server to sent single ping reply and exists. Then ssh comes into play. Be aware that grep can buffer output, so this is what --line-buffered is for.

You can wrap this command with bash function to use it exactly the way you've described.

$ waitfor() { ping $1 | grep --line-buffered "bytes from" | head -1 }
$ waitfor server.com && ssh server.com

function hurryup () { 
    until ssh -o ConnectTimeout=2 "$1"@"$2"
        do sleep 1
    done
}
hurryup root "10.10.0.3"

-o ConnectTimeout=2 is a slightly hacky way of getting around not responding to network packets, reporting ssh: connect to host 10.10.0.3 port 22: Operation timed out until it's responsive.

Then, when the host responding to network packets, the 1 second sleep with happen in-between ssh: connect to host 10.10.0.3 port 22: Connection refused as we wait for ssh to come up.

This uses socat to connect and wait for the server to say something, which will be the SSH version info:

while [ -z "$( socat -T2 stdout tcp:127.0.0.1:22,connect-timeout=2,readbytes=1 2>/dev/null )" ]
do
    echo "."
    sleep 1
done

Adjust host, timeouts, and sleep interval as desired.

You might not need -T2, which sets a timeout for inactivity after the TCP connection is already established, but in my case I was connecting to a QEMU virtual machine, and QEMU opens forwarded ports before the virtual OS is genuinely listening. It's harmless, in any case.