Osintgram on Kali Linux: install it, fix it, use it

Two things about Kali break an Osintgram install, and neither is explained by the pages currently ranking for this query. Both arrived after most of those pages were written.

The first is packaging. Osintgram is not in the Kali repositories, so sudo apt install osintgram cannot succeed no matter how many blog posts print that line. The second is pip. Since Kali 2024.4 the distribution follows PEP 668, so a plain pip install -r requirements.txt outside a virtual environment refuses to run and prints error: externally-managed-environment. The older Kali walkthroughs still ranking for this (kalilinuxtutorials, the 2021 Medium posts, dev.to) hand you exactly that command.

This page covers the Kali-specific parts only: the packaging reality, the PEP 668 wall, the Python 3.13 problem, the errors you see on a Debian-family system and nowhere else, and Termux. The platform-agnostic material (why a virtualenv, which Python version, how credentials work, Windows and Docker) lives in how to install Osintgram, and this page deliberately does not repeat it.

Is Osintgram in the Kali repositories?

No. We checked four independent sources on 8 August 2026; none of them lists it.

A 404 on the tool page alone could be a documentation gap. Four negatives across the tool catalogue, the packaging GitLab and Debian are not. The project agrees by omission: the Datalux/Osintgram README documents exactly one install path, which is a git clone, a virtualenv and pip install -r requirements.txt. There is no PyPI package either, and no installer script: setup.sh 404s on the master branch.

Why the old Kali tutorials fail now

Two things changed on Kali after most of those guides were written, and both of them break the copy-paste.

The first is PEP 668, which lets a distribution mark its Python installation as externally managed. Kali documents the behavior and the sanctioned ways around it: a virtualenv, pipx, an apt package, or the discouraged --break-system-packages override. Run the install line those guides give you and pip stops before it downloads anything.

error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try
    apt install python3-xyz, where xyz is the package you
    are trying to install.

    If you wish to install a non-Debian-packaged Python
    package, create a virtual environment using
    python3 -m venv path/to/venv.

note: If you believe this is a mistake, please contact your
Python installation or OS distribution provider.
hint: See PEP 668 for the detailed specification.

Only one of those four remedies applies to Osintgram. There is no apt package, as established above. pipx installs Python applications. It needs something pip-installable, and Osintgram ships no setup.py and no pyproject.toml, so there is nothing for pipx to install. That leaves the virtualenv, which is what the README told you to do in the first place.

The second change is the interpreter. The Kali package tracker lists python3-defaults at 3.13.9-3 in the rolling repository, so a current rolling install is running Python 3.13 by default; Kali 2024.4 was the release that moved the default to 3.12, and it has moved on again since. Osintgram was not written for that. Its Dockerfile still pins python:3.9.2-alpine3.13, an image from March 2021, the README states no minimum version at all, and requirements.txt pins three packages to releases from 2019 to 2021.

Installing those pins in a clean Python 3.11 virtualenv on current pip succeeds. We reproduced it, and prettytable and hikerapi, which publish no wheels, build from source without complaint. Python 3.9 to 3.11 is the band to aim for. On Kali that usually means accepting 3.13 and dealing with the fallout, or, if you have an older interpreter installed, creating the environment with it explicitly: python3.11 -m venv venv instead of python3 -m venv venv.

None of this is a swipe at those authors. A 2020 guide was correct in 2020. It is a warning about what happens when you follow a page that has never been revised: you end up fixing errors the guide created.

The install that works on current Kali

Six steps. Nothing here needs root except the first one; everything else happens in your home directory and inside the virtualenv.

1. 1

   Install the system prerequisites

   Git, the venv module, and the build tools that gnureadline needs if it has to compile. This is the only command that needs sudo.

   sudo apt update
   sudo apt install -y git python3-venv build-essential libncurses-dev

2. 2

   Clone the repository

   Clone it into your home directory. Tracebacks in the issue tracker are full of /home/kali/Osintgram/, which is as good a convention as any.

   git clone https://github.com/Datalux/Osintgram.git
   cd Osintgram

3. 3

   Create and activate the virtualenv

   This is the step that makes PEP 668 irrelevant. Do not pass --system-site-packages; that reintroduces the apt-managed copies you are trying to avoid.

   python3 -m venv venv
   source venv/bin/activate

4. 4

   Install the dependencies inside it

   Upgrade the build tooling first. The pinned prettytable==0.7.2 is old enough to fail against stale setuptools.

   pip install --upgrade pip setuptools wheel
   pip install -r requirements.txt

5. 5

   Fill in the credentials file

   The repo ships config/credentials.ini with three blank fields: username, password and hikerapi_token. Fill in either the Instagram pair or the HikerAPI token. make setup prompts for the pair and writes the file for you, but it drops the token line and resets your session cache. The credentials decision is covered properly in the install guide.

   nano config/credentials.ini

6. 6

   Run it against a target

   The username is a required positional argument: main.py will not start without one. Add -c <command> to run a single command and exit instead of dropping into the shell.

   python3 main.py <target username>

Two footnotes on step 1. python3-venv is usually already present, but on a trimmed Kali image it is not, and python3 -m venv venv fails without it; the PEP 668 message itself tells you to make sure python3-full is installed. build-essential and libncurses-dev are insurance rather than a hard requirement: recent gnureadline releases ship manylinux2014 wheels for x86_64 and aarch64, so on an ordinary Kali amd64 or arm64 box pip downloads a wheel and compiles nothing. Those two packages are what stops /usr/bin/ld: cannot find -lncurses on the machines where pip does fall back to the source distribution.

Kali install errors and what they actually mean

These are the failures that show up on Debian-family systems specifically, in rough order of how often they appear in the tracker. The error text is what you paste into a search engine; the middle column is what is really happening.

One row is worth expanding, because it sends people chasing the wrong package. On Linux you can get a pyreadline error. main.py opens with a bare try: import gnureadline / except: import pyreadline, and the environment marker in requirements.txt only installs pyreadline on Windows. So on Kali that message is never about pyreadline: it means the gnureadline import failed, which nearly always means the gnureadline build failed. Installing pyreadline will not help. Fixing ncurses will.

Running Osintgram on Kali

Three lines every time, and the first matters more than it looks.

cd ~/Osintgram
source venv/bin/activate
python3 main.py <target username>

src/config.py reads config/credentials.ini as a relative path, and main.py imports src.Osintgram the same way. Launch it as python3 ~/Osintgram/main.py target from your home directory and the config read finds nothing at all, or you get ModuleNotFoundError: No module named 'src.Osintgram', which is what issue #105 is. There is no install prefix and no wrapper script; the clone directory is the application.

Everything the tool reads and writes lives under that clone:

• ~/Osintgram/config/credentials.ini: your Instagram username and password, or a HikerAPI token.
• ~/Osintgram/config/settings.json: the cached login session. The cache command, or launching with -C, resets it to {}.
• ~/Osintgram/output/<target>/: results, as <target>_<command>.txt and .json. File output is off until you type FILE=y or JSON=y, or launch with -f / -j.

Once it starts you are in an interactive shell with a yellow Run a command: prompt and TAB completion over the command names. Be careful with the heavy ones: the four email and phone commands make one extra API call per follower with no backoff anywhere, and a Kali user in issue #366 got 41,643 records out of fwersemail before Instagram blocked the requests. The crash that followed discarded all of them. The full command reference, the output filenames and the ones that no longer return anything are in how to use Osintgram.

Kali on ARM, and Osintgram in Termux

Kali on arm64 needs no changes to the sequence above. gnureadline 8.3.3 publishes manylinux2014 wheels for both x86_64 and aarch64, so the one dependency that could demand a compiler usually does not need one on either architecture.

Osintgram in Termux

Termux is not Kali, but it is the other place people try to run this from a phone, and it is the environment where the compile is genuinely unavoidable. Android's bionic libc matches neither the manylinux nor the musl wheel tags, so pip falls back to the gnureadline source distribution, which means clang and the ncurses headers have to be there first.

pkg update -y && pkg upgrade -y
pkg install -y python git clang make binutils ncurses-utils libffi openssl
git clone https://github.com/Datalux/Osintgram.git
cd Osintgram
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

Termux reports platform_system as Linux, so the marker in requirements.txt selects gnureadline and never pyreadline; the Windows startup crash does not apply here. The most common Termux report in the tracker, issue #583, is just somebody running python3 main.py before installing the requirements and getting ModuleNotFoundError: No module named 'requests'. Everything after the package step is identical to the Kali flow, credentials file included, and so is the login problem below.

It installs. Then the login fails.

Getting Osintgram onto Kali is the easy half. The hard half is that a username-and-password login into Instagram largely does not work any more, and nothing you do on the Kali side changes that. If your install completed and the tool dies at Attempt to login..., you have not made a mistake.

The failure is server-side. The classic backend is instagram-private-api==1.6.0, pinned to an Instagram endpoint that has since been withdrawn, and the 2026 reports (issue #2627, March 2026) come back as checkpoint_required with a checkpoint_url of https://i.instagram.com/web/unsupported_version/. That is Instagram rejecting the library's API version, not your password. There is a second backend: put a token in the hikerapi_token field of config/credentials.ini, or launch with HIKERAPI_TOKEN=<token> python3 main.py <target> -c <command>, and main.py constructs a HikerAPI client instead, with no Instagram login involved at all. That is the path still designed to work, and users report it working. But it is a paid third-party service, it means sending your targets to that third party, and it has response-format breakage of its own, reported in issue #2664.

The full status picture (what broke, when, what still works and what it costs) is in does Osintgram still work in 2026. And if your target is a private account, there is a hard limit that no platform, fork or flag gets around.

When the install is not worth it

There is a version of this job where none of the above earns its keep. If you need public profile data on a handful of accounts, and you are not specifically trying to learn the tool or work offline, then the clone, the burner account, the throttling and the login failures buy you nothing you cannot get faster.

A hosted lookup also removes the part of the CLI workflow that carries real risk on Kali: you never put your own Instagram credentials in a file, so there is no automated-login ban to worry about. Same public data, no PEP 668.