I'm failing to connect to an SSH server instance and the verbose output contains debug1: Roaming not allowed by server. The following predictable and there avoidable problems arise:

  • Roaming means to access services from different types of networks. I can't figure out what it could mean in the context of the verbose output of a ssh 6.6.1 client running on Ubuntu 14.04.
  • It is not clear whether this is an error or not and if it is whether it is causing the failure of the login or not (I don't want to dive into the connection failure here, though; none of the output message of ssh does BTW -> more problems and time waisting - you have been warned!)
  • I queried site:www.openssh.org roaming in google with empty result and manpages don't contain the term. It is nonsense to use it even if it was documented because of its ambiguity!

What could the message mean? How could I use it to debug the large set of other highly ambiguous, unintuitive and unhelpful error and other messages of SSH?

4 Answers 4


It's not really an error message. It's just a debug message telling you that the server doesn't accept roaming connections.

Roaming is apparently an experimental feature added to OpenSSH back in 2009 or so. The purpose of the feature is to let an ssh client disconnect from a server session and then resume the session from another location. See here (Archive.org) for some discussion about it. Googling ssh, roaming, and "Martin Forssén" will turn up other pages. It doesn't look like it's being actively developed. I suspect the SSH developers never documented it because it's experimental and perhaps not finished.

From inspecting the OpenSSH source code, there's an undocumented client-side option UseRoaming which can be set to yes or no. Adding the line "UseRoaming no" to your client configuration (normally your .ssh/config file) ought to suppress the debug message.

It wasn't obvious to me why the server-side HostbasedAuthentication setting would control whether the server accepts roaming connections or not.

Update: The client roaming support is apparently the subject of a computer vulnerability exposure report, CVE-2016-0777. OpenSSH versions 5.4 through 7.1p1 are vulnerable. Users should upgrade to OpenSSH 7.1p2 or later. Users who cannot upgrade should disable roaming in the client by adding "UseRoaming no" to their ssh client configuration. See the following:

  • 7
    Well, it is now recommended to set it to no. mail-archive.com/misc@openbsd.org/msg144351.html
    – nikeee
    Jan 14, 2016 at 15:21
  • 1
    @nikeee: ...and that's a cautionary story for not shipping "harmless" non-working stubs. (Note that you need to set it to no in client settings, not on the server) Jan 14, 2016 at 15:28
  • 1
    @Piskvor but there's a quite a few devops / webops books that propagate doing that.. could they be all wrong? Oh. Jan 14, 2016 at 17:36
  • best explanation about this config on the net. Jan 16, 2016 at 21:24

The changelog from openssh 5.3 on CentOS6 has a note:

     Add client option UseRoaming. It doesn't do anything yet but will
     control whether the client tries to use roaming if enabled on the
     server. From Martin Forssen.

@ILMostro_7 chmod 600 authorized_keys worked fine for me.

For the benefit of anyone else who arrives here by googling "Roaming not allowed by server", and is using a Linux (Ubuntu) client, you might fix that warning and then see:-

Agent admitted failure to sign using the key

The cure for that is given at https://help.github.com/articles/error-agent-admitted-failure-to-sign/

    # start the ssh-agent in the background
    $ eval "$(ssh-agent -s)"
    # Agent pid 59566 (displays process id)
    $ ssh-add
    # Enter passphrase for /home/you/.ssh/id_rsa: [tippy tap]
    # Identity added: /home/you/.ssh/id_rsa (/home/you/.ssh/id_rsa)

'#' = comment. you = your-username. [tippy tap] = humo[u]r? = press the Enter key.

I hope that helps somebody as much as this Q&A already helped me.


This error message can show up when /etc/ssh/sshd_config doesn't have HostbasedAuthentication set to yes on the server.

I have no idea why.

Another issue may be:

Check the permissions on the $USER/.ssh directory which should be owned by the user and be chmod 700. The authorized_keys file should also be chmod 700 and owned by the user

  • 700? Why would you need execute bit on keyfile?
    – ILMostro_7
    Mar 11, 2015 at 10:32
  • Where's the quote from? Please add a reference. May 31, 2015 at 20:15
  • ILMostro_7 isn't not on the file, it's on the directory, and for the user to be able to create files in the directory, the execute flag must be set
    – IceyEC
    Jan 14, 2016 at 14:46
  • @IceyEC The answer suggests 700 for authorized_keys.
    – mdrozdziel
    Jan 14, 2016 at 15:12
  • 1
    Should be chmod 400. No idea why I'd ever want that file to be executable; and write access is also not desirable 99.999% of the time. sshd checks that the user's .ssh folder has no access for group and other, and likewise for .ssh/authorized_keys. Therefore, the perms in the answer might work, but they're unnecessarily wide. Jan 14, 2016 at 15:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.