Bug #1584

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

Added by corecode about 5 years ago. Updated 10 months ago.

Status:In ProgressStart date:
Priority:NormalDue date:
Assignee:tuxillo% Done:

0%

Category:Kernel
Target version:3.8.0

Description

When running ssh from a jail, I get:

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

can also repeat this:

# cat `tty`
cat: /dev/pts/4: Device busy

outside:
% cat `tty`
^C

cheers
simon

History

#1 Updated by corecode about 5 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:
>
> # cat `tty`
> cat: /dev/pts/4: Device busy
>
> outside:
> % cat `tty`
> ^C
>
> cheers
> simon
>

#2 Updated by check+l9606t00rspw4z28 about 4 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

#3 Updated by dillon about 4 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

#4 Updated by corecode about 4 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

#5 Updated by tuxillo 10 months 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.0

Grab.

Also available in: Atom PDF