can't use ssh from jail: debug1: read_passphrase: can't open /dev/tty: Device busy
|Status:||In Progress||Start date:|
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
% cat `tty`
#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
> % cat `tty`
#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 <email@example.com> 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:
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
(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.
#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.
#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