DragonFlyBSD

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

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 <corecode@fs.ei.tum.de> 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

: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

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