Project

General

Profile

Actions

Bug #1584

open

can't use ssh from jail: debug1: read_passphrase: can't open /dev/tty: Device busy

Added by corecode over 14 years ago. Updated almost 3 years ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
Kernel
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

When running ssh from a jail, I get:

debug1: read_passphrase: can't open /dev/tty: Device busy

can also repeat this:

  1. cat `tty`
    cat: /dev/pts/4: Device busy

outside:
% cat `tty`
^C

cheers
simon

Actions #1

Updated by corecode over 14 years ago

Simon 'corecode' Schubert wrote:

When running ssh from a jail, I get:

This is using jexec to get into the jail.

debug1: read_passphrase: can't open /dev/tty: Device busy

can also repeat this:

  1. cat `tty`
    cat: /dev/pts/4: Device busy

outside:
% cat `tty`
^C

cheers
simon

Actions #2

Updated by check+l9606t00rspw4z28 over 13 years ago

I'm not sure how to properly respond to bug tracker issues.
I hope it's ok to just post a follow-up.

Simon 'corecode' Schubert <> wrote:
> Simon 'corecode' Schubert wrote:
> > When running ssh from a jail, I get:
>
> This is using jexec to get into the jail.
>
> > debug1: read_passphrase: can't open /dev/tty: Device busy

That's not a bug, it's the way jexec works. jexec attaches
to an existing jail, but it cannot create a separate tty
within the jail. jexec is still connected to the tty outside
of the jail, and according to jail rules it is not allowed to
modify anything outside of the jail.

This FreeBSD thread explains it:

http://lists.freebsd.org/pipermail/freebsd-jail/2007-October/000106.html

If you ssh into the jail instead of using jexec, sshd(8) will
allocate a tty for you which is completely inside the jail,
so you can use ssh without problems.

If you don't want to run sshd(8) inside the jail, there's a
small hack so it also works with jexec: You can use script(1)
to allocate a tty:

host# jexec 1 /bin/sh
jail# script -qt0 /dev/null ssh user@somewhere
password:

(In fact I have an alias intty="script -qt0 /dev/null" because
this is also useful to have in other situations.)

I think this issue can be close.

Best regards
Oliver

Actions #3

Updated by dillon over 13 years ago

:I'm not sure how to properly respond to bug tracker issues.
:I hope it's ok to just post a follow-up.

Normally once it has a bug id but it isn't in the Subject so it will
not be able to track... well, don't worry about it.
There is another long-standing issue related to running sshd's inside
a jail, when they use the same port #. The sshd's inside are typically
bound to a particular IP address whereas the one outside is bound
to a wildcard address. Unfortunately that means the one outside
gets all the connections.
So currently to run a sshd inside the jail the one that is run outside
the jail needs to also be bound to a particular IP, if the same port
is to be used.
-Matt
Actions #4

Updated by corecode over 13 years ago

I think that's a bug. I'm quite sure I specifically took care that this issue
wouldn't happen (or rather, I talked with vbd about that).

The priority for routing SYNs to listeners should be:

bound to IP; bound to 0/0, inside jail with IPs; bound to 0/0 outside

Actions #5

Updated by tuxillo about 10 years ago

  • Description updated (diff)
  • Category set to Kernel
  • Status changed from New to In Progress
  • Assignee changed from 0 to tuxillo
  • Target version set to 3.8

Grab.

Actions #6

Updated by tuxillo almost 3 years ago

  • Target version changed from 3.8 to 6.0
Actions

Also available in: Atom PDF